Ask HN: Why is WebAuthn so slow to take off?
I wonder why I barely see this option on websites altough it seems so perfect to me. Is the WebAuthn protocol complicated to implement or are there any other downsides I might overlook? Passkeys is a new FIDO standard that will let the private keystore be backed by the cloud. It was added to WebAuthn fairly recently. Having keys tied to specific physical devices was a terrible & frustratingly limited scheme that never had any hope. Now that there's something a little bit looser, there's some small hope WebAuthn starts to become interesting & viable. https://developer.chrome.com/blog/webauthn-conditional-ui/ Another huge challenge is that there are so very many ways for developers to use this tech. There are a truly humbling amount of scenarios & flows one can set-up. Many of the most direct paths continue to have the user already set up an account via regular email/password, so users still end up doing the same account management anyways. I'm missing the link to the wonderful wonderful guide I spent a couple commute rides reading, but it was one of the longest most technical pieces I've read in quite a while. "Introducing the WebAuthn API" is perhaps a reasonably ok substitute. https://medium.com/webauthnworks/introduction-to-webauthn-ap... Also now your Windows Hello PIN and your screen unlock PIN on Android will be your master password to all websites. That's a huge new risk for real people.
On Windows they don't even bother making a password option which could at least imply that a longer PIN is possible. Windows also asks for the same everytime which strongly encourages making it short.
Although I suppose nobody cares because isn't your PIN already your master password on Android/iPhones for your appstore and payments... In short I don't think PINs should be allowed for use with webauthn and these devices should have a very user friendly configurable timeout so that users don't have to enter it nonstop. If I logged into my bank 5 seconds ago, maybe it's okay for me to also log into my second bank without prompting for my master password aka PIN again. The PINs protect a hardware enclave full of cryptographic keys. The PIN never leaves the hardware device it was input into. (It's an equivalent to the button on a Yubikey or something of that nature and there is a reason that PINs are lumped into the same settings as biometric unlocks like Touch ID and Face ID.) It's an intelligent trade-off, of course, in threat models that involve access to the physical device for threat models that involve remote access of websites and other resources. Yes, if everything uses the same PIN on a device then that adds to the risk of someone snooping your PIN, stealing your device, and accessing many things in the process. If that is the threat model that most concerns you, then yes, this makes things worse. But PINs can't be used remotely at all and never transfer across a wire. They can't be brute forced remotely over the internet. Having someone's PIN but not the specific device that the PIN unlocks doesn't unlock anything (because you still don't have access to any of the private keys on the device without the device). Websites only know your device's public keys. If you use entirely WebAuthn, breached websites only leak public keys. If your threat model involves concerns about internet hackers or the daily breaches we see in services like haveibeenpwned, device-specific PINs are a massive improvement. Yes I was thinking of the theft scenario, for remote usecases it is definitely safer. I think webauthn could be great for 2fa without phones. But there are important things missing. For example the google authenticator app has an established way to backup and sync now. There is no such manual backup and sync possibility for Windows Hello passkeys. It's all a bit new now. I suppose as a website owner I would have to let people register multiple passkeys and then the user only has to have one of them to successfully log in. Hm it might be okay. And of course Chrome already added sync support for their passkeys but you can't rely on everyone using Chrome. > Yes I was thinking of the theft scenario, for remote usecases it is definitely safer. The thing to keep in mind is that the remote threats are bigger and more common, and the "local theft" scenarios fewer and impacting fewer people. Obviously, it is terrifying as an individual user when a device is stolen with enough PIN information. But on the other hand, you can't so easily automate stealing devices physically from people. It is much harder to steal things to anything like the same degree of mass stealing credentials in remote attacks and database breaches. For most ordinary users, they are much more at risk of remote attack or remote phishing than local theft. Device PINs are probably the right balance for the average user's threat model. (If you have larger concerns about device theft than the "average user", then plan accordingly. Find the right mix of other offered unlocks and snoop prevention mechanics as feels right to you.) > But there are important things missing. I think at this point in your post you are confusing Webauthn/FIDO keys in general and Passkeys specifically. In general, websites should absolutely allow you to register an entire keychain of public keys beyond just any single device's keys. (It's often the sign of a bad Webauthn implementation if it only allows a single key.) Passkey standards themselves are an extra couple of levels of Webauthn standards on top of that. They include things such as synchronization of keychains, including recovery keys, manufacturer attestations about keys ("this key comes from the secure hardware enclave of an iOS device"), and the use of Bluetooth LTE for local FIDO key delegations (using a QR code to kick off a handshake between your Windows PC and your Android Phone to sign something over Bluetooth LTE, and Bluetooth LTE with physical proximity only). The general goal of passkeys is to have keychains with keys from every one of your devices represented plus the ability to say that "these keys are somewhat more important" such as the keys from your personal phone as the true "master keys" of your passkey. Apple, Google, and Microsoft have all agreed to interoperate in their implementations of Passkeys. In theory, the Passkeys keychains should all eventually "merge" into a single synchronized keychain representing your entire device ecosystem, generally with your personal phone as the "lead" or "head" at the table. In practice, for now, most Passkeys operations I believe still should assume that a user has N Passkeys (and N times M keys in general). But yes, Apple is currently in the lead with Passkeys implementation (with UX in all of iOS, macOS, and Safari) and Google isn't far behind in Chrome implementation (though I hear Android is somewhat behind still) and Microsoft currently has the most "catch up" to do in terms of Passkey UX. So instead of having a physical device you own act as a second factor, you are now vendor-locked to a proprietary authentication solution for the entire login process. No thank you! The entire point of two-factor authentication is to have, well, two factors: something you know and something you have. Using the PC itself as token was already problematic enough as it has a massive code base and runs all sorts of untrusted code so it is likely to be compromised at some point - but at least that was somewhat excusable due to convenience making it accessible to way more people. But getting rid of the rest of the credential and solely relying on the OS is just insanity. I didn't like how unmanageable physical devices were. If I could make a backup of those keys, I would have been happy with physical devices. But every time I make an account somewhere, I have to go add devices in triplicate? Ugh it was such an abysmal terrible experience. Physical devices are just too unreliable & too constrained as systems. Passkeys, to my knowledge, are an extension of FIDO Alliance standards. My hope is that one can bring your own provider. This would avoid the vendor lock that has you quaking. > My hope is that one can bring your own provider. Everyone always says this, but it's always just a hope. And given the history of the FIDO Alliance standards on backing up keys, and given the players involved, I think it's reasonable to say that people just straight-up should not use passkeys until it's not a "hope" and backup/migration actually works as part of the standard itself. Note that this doesn't mean: - Migration is allowed but not mandated. Migration must be built into the standard or else vendors will eventually introduce lock-in in the future under the guise of security. It can not be optional. - Migration is allowed through special contracts using some locked-down behind-the-scenes company-to-company transfer. I need to be able to sit down on my Linux computer with an Open Source piece of software that I compiled and I need to be able to move the keys from my iCloud account to that software. I want to assume good faith from the FIDO Alliance standards, but some of the messaging around this has been straight-up deceptive. 1Password advertised itself as solving the portability problem, but last I checked it doesn't. 1Password is device agnostic but does not allow exporting your passkey information to another account. I've run into so many scenarios where advocates straight-up misrepresent what portability means that I now give really specific tests instead, because otherwise the conversation doesn't go anywhere. I keep running into advocates that tell me "it's usable today" and in the same breath tell me "it's early days, we'll get to the portability stuff later." So the specific criteria is: if I can't compile my own software on a Linux computer and move my "keys" or whatever authentication mechanism is tied to that account into that software as a single operation without logging into and re-validating every single account individually or adding another authentication mechanism to each account, then it's not portable and I'm not using it. It needs to specifically allow for that, and there needs to be a real working Open Source project that I can run today that allows it. Otherwise, it's not actually portable today. Furthermore, if I do compile my own software and move in those keys and then I go to log into a website and a service refuses to let me log in because I've failed a hardware attestation check and I need to use an Apple device to log in -- then it's not portable. That cannot be something that the spec allows or encourages, or it's not actually portable. But (and as always, I would be thrilled to be proven wrong about this) the spec itself allows for that kind of behavior with hardware attestation with basically no downside other than a "please be a nice company and don't do this" warning, and noise from the FIDO Alliance advocates I've seen online is that they don't want to mandate a specific migration format in the spec or make migration a requirement for companies that want to advertise that they implement Passkey; they want to leave that process up to individual companies under the "hope" that those companies will do the right thing. I'm not just not adopting Passkeys, I'm actively discouraging adoption of the standard until that's fixed. I'm not signing into a locked-down ecosystem under the hope that it might become more open later in the future, maybe. There's a version of Passkeys that I would be excited about and that I would build support into my projects for, but it's not the version that exists today. Not only that. It defeats the purpose of using a dedicated device. Which the masses were never ever ever going to adopt, not in a million billion years. it still seems pretty bad ui wise, prompting me to scan a QR code on desktop: https://webauthn-conditional-ui-demo.glitch.me/create-accoun... I was ready to give up until I realized that maybe "internal sensor" means Windows Hello on my machine and yep it does. But no real user is going to click through these security sensitive popup dialogs until Windows Hello shows up as an option. My verdict is that it's still clearly only for techies.
And when I cancel the dialog it prompts me to "setup my security key". Just terrible ui, nonstop popups. Edit: Firefox shows me the Windows Hello option immediately, that should be the default on desktop. My daughter recently had an unplanned "remote learning" day because of snow. One of my daughters assignments required her to log into an app. At school they do so by scanning a QR code they keep in the classroom. The teacher sent a picture of the QR code. I found myself in the hilariously absurd situation of needing my laptop to scan a QR code it was displaying on its own screen. I took a picture with my phone and then presented the QR back to the computer. Your comment reminded me of this. I use 1Password for TOTP. It has a screenshot option to scan the QR code during setup. It's handy. On Firefox on my Android phone it's phrased much better: "Use this device with screen lock". But that doesn't sound like something I'd ever want. Obviously I want to be able to log in on my computer too? it seems I entirely missed the red text on Firefox that says "Your browser does not implement Conditional UI" so what Firefox did was to probably prompt for the old WebAuthn and I guess that's Windows Hello which makes a lot of sense to me.
I wonder whether Firefix will also show me the QR code signin as the default on desktop once they implement it. Like you said...in my opinion this makes no sense, obviously as a desktop user using a desktop site I want to remain on my desktop hardware device. Or am I misunderstanding you and you want to log in on desktop with the same passkey that you generated on mobile? I think that is never supposed to work, it's supposed to be tied to the device. > Having keys tied to specific physical devices was a terrible & frustratingly limited scheme that never had any hope. I disagree. I think it's great having it all under my own control. What's important though is to be able to add multiple keys which many sites don't offer. Having my keys under control of apple or Microsoft sounds to me like a terrible and frustratingly limited scheme. But passkeys doesn't rule out physical keys so if people want to get deeper in bed with big tech they can, while I can keep my physical keys. is passkey any better than a password manager, besides losing the option to set your own secure password that you can store offline? Fully managed passkeys will always have the max needed entropy without any need for KDFs, never be reused, are amenable to a smooth path to hardware backing, and most importantly/fundamentally aren't symmetric factors. You don't need to share the private key with the website, and that in turn means that even if you stored it in plain text on your own computer you're still immune to the most common form of leaks which is services themselves getting hacked. Password managers make it easier to change a password after a leak has happened, but moving to a proper key based infra means that leaks simply no longer matter. It doesn't matter in terms of auth if attackers get a public key. While having more hardware backing on top certainly has advantages too, it's the symmetric nature of passwords that have always made using them in a shared environment a fundamentally bad idea. Practical advantages of moving on like eliminating all the stupid legacy password policies and so on in one fell swoop are nice as well. >besides losing the option to set your own secure password that you can store offline? There is nothing inherent that would stop passkeys from being converted to base64 and printed on paper same as any key, and part of the point of them is being able to back them up all the normal ways and have them secured with a good password or other option that never leaves your own control. Which of course you can then print out. As I recall it, this is more or less what Mozilla wanted to do with Persona back in the day. That didn’t take off, but the approach with WebAuthN is perhaps an evolution of it especially in terms of making public key crypto user-friendly. Of course, the challenge is different in a multi-device world when you want your phone, tablet and laptop to all use the same login without using a hardware key. If the password is properly managed, how does it matter if its hash leaks? Two major problems with holding passwords server side as hashes:
1) Every authentication attempt needs to send the password as cleartext (even if over TLS) so that the hash can be recomputed server side and compared. This gives ample opportunity for the password to be intercepted either over the wire or compromise of infrastructure server-side. Using asymmetric encryption doesn't have this vulnerabity. 2) Passwords that can be stored in the meatsack attached to the keyboard aren't as random as we'd like to think them to be, where as a secure pseudo-random function will generate keypairs with unguessable entropy. Expanding on 2) While salting and non-uniform iteration counts of hashes prevents instant compromise from rainbow tables, they only slow down adversaries generating hashes from password guesses, as the salt and iteration count will typically be leaked from the same table as the password hash. Its worth noting that while it definitely is infeasible to attempt to crack 100K+ users passwords from a password hash leak, using password spraying and especially password stuffing approaches will inevitably lead to compromise one or more accounts relatively quickly. At the other end of the spectrum, if a known high-value account can be identified, dedicating the distributed cloud resources to cracking a specific password can be a net-profitable undertaking. A secure pseudo-random function will generate passwords with no less entropy than your keypairs. Builtin password managers in browsers do that. And if the server is compromised, the attacker doesn't need your credentials at all: he already has more access to the server than you ever had. If nothing else, it has more bits of security than a password has & so is less crackable. It's also an official standard that should integrate effortlessly into apps & websites alike. Password Managers are- as far as I know- all bespoke solutions with their own custom implementations. Not having a common interoperable framing for implementation & extension limits user's control & optionality. The other major advantage is that sites don't need to support "Passkey". They support Webauthn. Then the user can use what the user wants to use. If they want to use a hardware key, go for it. If they have a user agent that implements WebAuthn by carving their keys in a stone tablet & using computer vision to read the credentials back, they can use that. Standards enable flexibility which enables possibility. > Standards enable flexibility which enables possibility. what?! standards are the opposite of flexible. by definition. here's something that is better than webauthn, published and battle tested since 2018, and nobody cares: https://hacks.mozilla.org/2018/11/firefox-sync-privacy/ it have all the advantages of webauthn, plus it is truly on-device, no middle man, you can easily recover keys simply by having more than one device... no server can read or data. only silly thing is that firefox insists on shipping with the auto-fill option enabled by default. only feature missing that this thread seems to brings up is support for external usb devices (which i personally don't care for, but is probably on the roadmap) -- i'm blocked from adding replies, so replying here: > it does passwords not keys well, that is what worked on 100% the internet in 2018 (and today, ha!). But it is a data store where you have full control. ironically this is what gives true flexibility, a well designed system with fully open source implementation and apis, not spec by ad vendors as claimed before. anyway, The existing browser implementation does passwords (and bookmarks!!!) but you can extend to be a distributed yubikey if you'd like. nothing is blocking you. as I said, it is something better than a hardware store, better than a cloud broker for your identity, etc... but nobody cares. And now that FIDO has marketing from the big Advertisers everyone wants it yesterday. Firefox syncs passwords, not keys. Passwords can be reused, stolen, or leaked, all of which cannot be done to WebAuthn keys. If I am not mistaken, all Passkeys implementations allow keys to be synced between multiple devices. This means it is by definition possible for them to be stolen or leaked. Webauthn keys are only secure against stealing & leaking if they are backed by a proper separate token like a Yubikey, but it seems the People That Be want us to get rid of those ASAP. To my understanding, Passkeys implementations don't sync private keys, they sync and cross-sign public keys. Some vendors may also add "recovery" public keys to those synced keychains so that you can "Forget Password" your way out of a lost device or locked account or bootstrap new devices, and you have to trust your chosen vendor's security for how they manage that private key for any "recovery" keys. But my impression is that there isn't anything that Passkeys is doing that you couldn't do by also collecting Yubikey public keys by hand and making your own keychains if you are sufficiently motivated. > To my understanding, Passkeys implementations don't sync private keys, they sync and cross-sign public keys. I haven't seen anything in the FIDO alliance or vendor (Apple, Google, MS) documentation to suggest that they're cross-signed public keys - can you point to some that I may have missed? The reason why I ask is on the face of it, it doesn't make sense to implement in this way: It would mean that each new device would have its own keypair per service and cross signed by at least one other trusted device.
Which could be fine, but now each service needs to store n public key pairs (one per device) after validating that the new key has been signed by a known key. Then, when a new device is added to the Keychain (in apple's case), that device needs to generate m new keypairs for m services, have them cross-signed and then proactively registered for each service. It does make sense to implement it as the person you're replying to suggests, where a shared private key is shared over an authenticated, end-to-end encrypted process - with the corresponding weakness that if the authentication method for adding new devices to an existing Keychain is compromised, so are all passkeys. Hence the question. From my understanding, it's complicated to find a way to say it never does a certain thing because Passkeys technically checks the "All of the Above" box and does a little bit of everything PKI can do, because it is explicitly multi-strategy for redundancy/resiliency/speed/ease-of-use reasons. I hedge some about my understanding of the current WebAuthn/FIDO/Passkey standards as my view of the Passkey model is still somewhat filtered through my old understanding of Keybase's "sigchain" model when they moved to device-based keys: https://book.keybase.io/docs/server#meet-your-sigchain-and-e... So far as I'm aware, Passkeys doesn't deviate too much from how Keybase had been built post per-device keys [1], albeit with more OS/platform support and fewer blockchain/cryptocurrency distractions/acquihire-risks. There are a hierarchy of keys (and yes it is generally always N keys involved and a complex keychain; websites may not see the whole keychains, though) with the most trusted being the keys that are non-exportable and therefore hardware device-specific. (Those keys get additional "attestations" attached specifying those extra trust characteristics.) Every one of a user's devices would generally learn and cross-sign each others public keys to recognize each other. There's a definite N key relationship between them. Device keys are then used to bootstrap more keys. Each subkey is more ephemeral (shorter expiration date) and less "trusted" than the last. These subkeys may be website-specific. These subkeys may or may not be shared between devices. When shared between devices it may be peer-to-peer, device-to-specific-other-device, end-to-end encrypted with device-specific keys. When shared between devices it may not even be in the form of a key but a shared "pepper" (relative of a hash "salt") to be mixed with website-specific call/response into a key-derivation function (KDF) of some sort. The keys may not be shared at all and instead a CA-like approach is used that if the subkey is signed by a known device key it is accepted. The keys may not be shared at all and instead data to be signed is sent encrypted to a specific device (a roaming phone, for instance) and that device signs it with a hardware key then encrypts that for the requesting device's ears only and passes it back over close-proximity-only Bluetooth LTE. Or nearly that same thing, but data being signed is a temporary key from the originating device. Additionally, vendors may add their own keys to the keychain for easier "recovery" in "Forgot Password" situations. Many of these keys might be subkeys of some cloud-based HSM and shared in similar ways (directly to specific devices after handshaking on device-specific, unexportable keys; KDF-built using a combination of "pepper" secrets known to the user and known to the cloud provider; some other thing). All of this is highly implementation specific which specific strategies are in play in any given interaction. It will likely also be highly vendor specific which ones they prefer. It is also somewhat website specific: websites are allowed to suggest they are "important like a bank" and will only accept the most highly attested keys (the non-exportable, device-specific kind). Websites might only want one-or-two degrees maximum distance from a highly attested key. I believe in rare situations websites might request as much of the signature graph as they can. The whitepaper [2] shows the two "new" WebAuthn Level 3 "use cases": lots of device keys sharing some more ephemeral keys. Lots of devices referring to a single other device for keys. Passkeys uses both/either as needed. To properly support Passkeys doing ephemeral key tricks, websites do need to store N keys per user, but that's always been a soft-requirement for good WebAuthn support. (In the case of secure FIDO tokens well before Passkeys, there's no recovery path without N key support.) In general, a User's "passkey" is most likely never represented by only a single shared private key, it's an aggregate hierarchy of keys from non-exportable device keys to temporary keys shared between devices to ephemeral keys made of "salt and pepper" and everything in between. Lots and lots of keys that generally know/trust each-other is much easier to secure than one-key-to-rule-them-all. There may even be as many as N * M keys in cases where every website has a different key for every user device. Long story short: "[they] don't sync private keys, they sync and cross-sign public keys" is subtly wrong short-hand because they may sync all kinds of temporary/ephemeral private keys and/or private data device-to-device. But even given ephemeral private keys it still feels more to me, and my understanding/my ability to elucidate my understanding, like describing that as cross-signing public keys as the "simple, short answer" rather than list all of the surprisingly many and complex ways they might be created and/or shared. [1] https://book.keybase.io/docs/server#meet-your-sigchain-and-e... [2] https://media.fidoalliance.org/wp-content/uploads/2022/03/Ho... WebAuthn I think proves quite well how a common abstraction can enable constant ongoing growth & expansion. This case alone is a clear win for standards being a way to get the ball rolling. Web Standards also tend to define what things look like for the page. They're a common interface for the developer. This does come with some constraints (but often some freedom/extensibility points are baked into specs too). What's notable is that implementation is replaceable. Different browsers can do different things, expose things in differnt ways. Users can also deploy Web Extensions to modify or monkeypatch or polyfill webapis in ways that they want. This is another key advantage of standards, that they create a common target which is user-instrumentable. Without standards, users are forever adrift & subject to the mercy of the various proprietary implementations. 1Password has passkeys in beta. Your password cannot leak, because it does not exist. Passkeys can also not be phished. Cannot be phished by currently known methods. Trust me, sooner or later they will find a way. Either through specific implementation issues, workarounds etc. Remember when everyone shrugged off concerns about sms 2fa codes? The WebAuthN standard (and corresponding browser implementations) do inject browser supplied attestation of the requesting domain, so only a horribly broken implementation would sign a request for mail.google.hackers.ru with the key provisioned for mail.google.com - the user has no input into what the browser supplies, hence its phishing resistance. That being said, there's no end-to-end verification of the server, so any DNS-poisoning or proxy-MITM-ing of traffic that presents a certificate trusted by the browser will validly present the Passkey implementation a domain that matches a validly provisioned key, allowing session hijacking or the start of oracle attacks on the private key itself. Also: phishing the recovery passwords to add a new device to the synched keychain is definitely a thing. Wow, the main reason to use a dedicated device is to avoid someone else get access to the keys without physically accessing the device. And now the key is voluntarily surrendered. I'm glad it's slow, the current "solution" to tie your credentials to a device that can be lost, stolen, or broken with the option to sync them to a cloud controlled by big tech companies is abhorrent. And adding more devices is not the answer either. hard disagree. my favorite workflow for high value accounts is webauthn backed by secure enclave with hardware key backups. it's really low friction from ux perspective and it frustrates me when sites don't support it. what's your key backup/recovery strategy? recovery is easy. i'm a customer of all these companies so i have faith i'll be able to convince them i'm me if it comes to that. and i keep a handful of hardware keys to make self-recovery easier if i lose or break one. most of my practices are to mitigate risks i personally know how to mitigate, and doing it while causing myself as little headache as possible. being able to auth using touch id on my personal laptop is great for day to day usage. Also, if you use iCloud for passkeys, Apple has has a procedure to regain iCloud access with a recovery contact: https://support.apple.com/guide/security/account-recovery-co... (No, that doesn't mean that the contact has access to your account, the encryption key is split between the contact and Apple by the device.) So I assume you do not consider, say, your Github or Google account to be high-value? Plenty of tech companies have simply started to refuse recovery if you lose all your 2FA keys. What do you do without 2fa if your account is taken over? I’m trading that risk for something more in my control. Yeah it would suck if I lost all my hardware keys, my laptop, and paper backup codes, and additionally I couldn’t get support from anyone. You're listing only the negative aspects, but in truth it's all tradeoffs. What you get is fishing-resistant authentication, that's pretty easy to use. > And adding more devices is not the answer either. Why not? What's your ideal authentication solution? Two things I'd love to see: Something like Mozilla Persona, and maybe SSH key authentication in the browser. No idea how I'd manage and back up my key though. Don't think it's easy for the broad masses eitehr. I really only see the negatives here. This solution offers me nothing over my password manager other that way less control over my own stuff, more ways to be locked out of my accounts, with the slightly added benefit that I don't have to worry about a sites shitty security practices. > What's your ideal authentication solution? I've said before as soon as passkeys can be managed offline and aren't tied to devices I'll be all in. Keepassxc is my preferred solution just now. It seems that they are set up to be like this already. At least Chrome+Android treat these passkeys like any password and they can be synced and accessed via API. I already see my passkeys in Chrome btw.
https://developers.google.com/identity/passkeys/supported-en... This sounds pretty good to me, this is therefore like a regular old password except it's a cryptographic key that I don't have to remember and it's secured by whatever device PIN or face unlock that the device has.
I think this might have a chance to succeed. Unfortunately the UI popups they implemented are not good, they need to remove the "usb security key" option and hide it under an advanced options tab. Anyone who uses that is an expert, please only prompt for the default device verification, like Windows Hello or face unlock on an iPhone. Also the fact that Chrome by default prompts for a QR code + mobile signin flow is a bit crazy to me, it seems they are very confident that everyone who has a desktop wants to login via phone. Which makes no sense to me, do I really want to use my phone to login to all my desktop applications? I don't think so, maybe younger people who only have laptops + phones do this but still.. why would this be the default, surely Windows Hello or whatever MacOSX uses on desktop is still faster than picking up my phone constantly.
I tried it and I was very surprised that it almost worked flawlessly. It asked me to automatically turn on my bluetooth, it connected to my PC's bluetooth within seconds and actually created a working login for my desktop via my mobile phone. It's impressive that this worked... except for the part that the "sign up" popup on desktop never went away automatically! > It seems that they are set up to be like this already. At least Chrome+Android treat these passkeys like any password and they can be synced and accessed via API. That same link shows that not only is this unsupported on Linux, there are no plans to support it on Chrome Linux. That's a far cry from "like any password". If it's just an API, is the issue that there needs to be a Linux provider that offers that API? Are there plans to work with the community to build one? Is that Linux provider going to run on custom kernels, or will it only run on a signed Ubuntu image? As it stands today, I actually can't use Chrome's WebAuthn implementation on any of computers except through its back-up "use your phone" method, which is a lot more inconvenient. And Google is telling me it has no plans to support my computers. Meanwhile, if someone uses passwords, I can tell them to switch to Linux and I don't need to provide the caveat that they won't be able to log into any of their accounts now without using a phone. > This sounds pretty good to me, this is therefore like a regular old password except it's a cryptographic key that I don't have to remember and it's secured by whatever device PIN or face unlock that the device has. So is my password, because I use (password manager). > this is therefore like a regular old password Well that's part of the problem, isn't it? It is being treated as if it is 2FA, but in practice it is barely more secure than a cloud-synced password. > with the slightly added benefit that I don't have to worry about a sites shitty security practices. I mean, here's the thing, I already don't have to worry about a site's shitty security practices because I'm using a random password for each account. Sure, my email could be leaked, but it's available on my CV anyway so, uh, congrats? > What's your ideal authentication solution? Client side TLS certificates used in combination with username/password. Had browser vendors improved the UX experience in generating CSRs and storing certificates, then it could have been a viable option. The nice thing about this is that it's application level protocol agnostic. It could even be used for SMTP and IMAP connections instead of just being limited to HTTP like webauthn. As stated, devices fail, or get stolen. When I’m traveling and robbed, I won’t be able to get the backup device is hidden in my drawer at home You also won't have access to the TOTP backup of emergency codes.. If you get hit on the head or have the trauma of your life you might not have a password. These are tradeoffs that people use to balance security. Many people will lose to a sim swap despite not needing access to their life savings while on vacation with absolutely no proof of identity and a fallible memory. > TOTP backup of emergency codes These are encrypted in my password manager that is sync'd to the cloud. I only have 1 password and 1 backup code I need to memorize. Sure, and achieving only 1FA with 2FA primitives and hoping you never encounter a keylogger is also a trade off.. I sync my (encrypted) OTP secrets between all my devices. > Two things I'd love to see: Something like Mozilla Persona [...] Passkeys is relatively close to being a proper successor to Mozilla Persona. The UX isn't quite as polished as Mozilla Persona felt, but Passkeys is a multi-vendor coalition with Apple, Google, and Microsoft all throwing marketing weight behind it, so maybe the UX will never quite be perfect due to the intersection of all that, but the underlying tech is really close to what Mozilla Persona proposed, in a long, round-about away. does the standard mandate any of that? Kinda of. one very important thing everyone overlooks when talking about web standards, is that they are written by Advertise vendors. Mozilla was the only W3c contributor that was mostly isolated from that conflict, and it was only a single degree! You can continue to ignore, but please, try to deny if you can before down voting. The backends are either cloud controlled (hence associated with your subscription) or device controlled (associated with the serial number, purchase, drm... ignore your fancy key, everyone will use the TPM in their laptop/phone). And yes, All protocols have similar restrictions to hide information from one side and another (publisher, relying party, etc) but none are better than the isolation you get today with same-origin. And those were put in place by the same advertisers, so it will not be a problem either. Not sure everywhere else, but within the Ruby community the ‘devise’ gem is most popular auth plugin. Discussion are currently underway as to how to refactor the code to make passwords second class citizens. And further whether to factor in design for MFA or just to bypass straight to adding passkey support. It’s major replumbing to essentially move username/password to be one of many, within the auth framework. Once this is resolved in devise thousands of Ruby/rails apps could add support overnight, but it seems to be getting a little stuck on the question of the best way forward (and someone to do all that heavy lifting). Join the conversation if you have something valuable to add: My guess as someone who's been in a position to implement it a few times but haven't gotten to: - "Upstream" Support, For various combinations of stacks I've worked on, there has always been one component that didn't support it cleanly, (Flutter x Ory was my last attempt for example). If it was as easy as "just" enabling it I'm sure it'd be more popular, but when your provider or tech stack doesn't support it out of the box it's usually not worth the effort to implement it from scratch. - Customer support. This has many sub problems. At my current job, customers get confused between social login and email/password all the time. Adding a newer more complicated technology would be a recipe for disaster. Similarly, because my job deals with money in a country where mobile theft is fairly rampant, the additional burden of trying to reassociate a users public key/account/device is problematic. Finally, I think the concept of managing private keys for a user is fairly complicated, though with passkeys and google/apple syncing your private keys for you I hope to see this burden fall away, and with it the rise of webauthn This is it, really. Companies have incentives to adopt this at the moment. What was the issue with Flutter and Ory? (Going from memory) we used firebase and had access to the native authentication SDKs, then we we switched to ory, we had to hack it back in because the documented way to implement ory would have used browser authentication. Ory provides a javascript bundle you load to do webauthn, which (again IIRC) didn't work inside the browser inside the app, and although we figured out some workarounds, would have conflicted with how we implemented the native auth. I would say because it relies on an hardware key, which few of your users are going to have anyway. Any tech requiring an hardware component is going to be much slower to deploy. I know there is still much interest in deploying it for internal/employee authentication in large organizations where you control the app login and the employee hardware. Some organizations that wrongly deployed multi factor auth based on SMS have realized that was a poor choice and are looking for alternatives. > I would say because it relies on an hardware key This isn’t true on Apple, Google, or Microsoft devices which have a trusted hardware store – I use my MBP’s Secure Enclave for 90% of my logins since it’s just a Touch ID check. Well, there is a hardware key, it's just that it's the device you're using. In other words, having a hardware key is not a real barrier to use. The opposite. It's a barrier because most users don't have one. …and yet most users are browsing using a device which itself contains a hardware key… and thus it is not a barrier. What if I don't like viewing web pages on a phone? Right, but that gets rid of the objection: there’s no second thing to buy and carry around, it’s faster, and it’s more secure than the alternatives. I'm not a huge fan of removing the 'two' from 'two factor authentication'. If people can login with just their device, which could be stolen, I don't think it's as secure as a password+device based 2FA alternative From a practical standpoint, i dont really think it matters. The real threat 2fa auth solves is the fact people blame the site operator when they are hacked. 90% of the time it is due to reusing a password. The other 10% it is due to phishing. WebAuthn stops both. 2FA works not because it adds another factor, but because it removes choice from the user so they can't screw it up. Interesting take on 2FA. The user not being able to screw up is of course important, but the second factor (something you have) works primarily because it is tied to something physical and therefore local to the user, which is not subject to remote attacks. The average user is not typically subject to remote attacks. There are exceptions of course. However we should design the default security experience for the threats the average user faces. Most users aren't being targeted by the NSA, etc. Unless you mean the webserver they use being attacked, but that is just as vulnerable for 2fa. The only difference is the user cannot screw up and use the same credential on multiple websites with 2fa. The average user isn't targeted personally, they are targeted en mass, the more people fall into the category, the more valuable target they become. A personal attack is needed only if the credential storage is not standardized. Remote attacks (e.g. say having a zero day in the sms messenger app. Not talking about remote in the sense of phishing emails are sent remotely or when attackers target service providers instead of users) typically get noticed and fixed really fast if they are used en masse. In practise it is much more common for attackers to pick specific targets in order to preserve how long their vector lasts for. Don’t most people that this this “correctly” use a password manager which stores passwords on the same device as stores the totp token and generates the one time code? Doesn’t this effectively turn your password into a device that you have, effectively turning the first factor (something you know) into something you have, while the second factor (something you have) is the same thing you have from the first factor (your phone)? Even people that do this incorrectly and reuse passwords, probably also store their passwords in their browser, which is on the same device as their authenticator app. So I would guess by far majority of people are only using something they have twice. I'm not sure about "most people", but I for one never stored 2FA tokens on the same device as my passwords. My password manager is only on my desktop/laptop, and my 2FA tokens only live on my smartphone/Yubikey. Storing both on one device sounds like a pretty stupid thing to do. Sure, it's convenient, but you are putting a looooot of trust into the assumption that your single device will never be compromised. How do you enter a password on your phone than? Do you manually type them after you reveal them on your desktop machine? That’s the trade off being made for convenience. It’s still somewhat multifactor though (I’ve seen people call it 1.5FA); authentication codes have the benefit of being resilient to replay. So, you’re not pwned even if someone steals your password somehow. Even if someone steals your phone, you should have a passcode. If they know or guess your passcode, well… someone could steal your house/car keys too, and we still carry them around anyway :) If we are assuming that the password manager is on the same device used to login, a replay attack is bordering on rediculous. In this scenario, you are assuming that the client is not compromised (since otherwise they would just steal it before you use it) the server is not compromised (otherwise what is the point), you do not have an active mitm (otherwise they could use the token directly instead of replaying). All that really leaves is you have someone capable of passively eavesdropping a TLS connection (usually much harder to do than active mitm). I suppose someone literally looking over your shoulder or recording you with a hidden camera - but even then they just have to out-race you hitting submit. Anyways. Not a realistic threat in my mind. Sorry, I meant replay really broadly because I could not come up with a better term in the moment. For example, a password can be leaked in many ways (guessed, by a breach if the website has poor password storage, etc) and be “replayed”, as in the attacker just enters the password themselves. A code does not have that problem because it is temporal. Ah ok. Its confusing because one of the requirements for time based one time password 2fa is that if you use the same 2fa token twice,it is still supposed to reject the second one even if it is in the same time window. On the server side usually a "key" is stored, which for TOTP based 2fa would allow the attacker to create future 2fa tokens if they got ahold of the key. So what really saves you is the website choses the key not the user, meaning every website has a different one. Not the temporal nature. Anyways, usual term for what you are referring to with reusing passwords is "credential stuffing". Here's the concept. Perhaps we have the order wrong. Maybe the physical factor should be the primary factor. The second factor should never be transmitted, but rather is used to unlock the physical factor. Requiring a password for a hardware key doesn't add much to the key already being in your pocket or locked in your house/office. It helps against an attack that's specifically targeting you as a person but it's basically just a nuisance for you when considering generalized account attacks. Not really part of what you said but this just caught my attention and I thought I'd ponder about it in public a bit. We used to think that > It helps against an attack that's specifically targeting you would be sufficient, because, like who cares about little old me?
But in the era of API intelligence, setting up a specific agent to target every person seems automatable. If all that was missing before was a sufficiently-motivated attacker who would learn about you and your patterns, and that couldn't scale because we didn't have enough dedicated bad guys, that seems like it's a bout to change pretty quick. Be careful to not lump all 2FA together: only FIDO2/webauthn second factor is immune to phishing. evilginx will happily steal most other 2FA (TOTP, ...). On Apple platforms, a biometric authentication is required to proceed with webauthn, so technically it is 2FA (something you have and something you are). Which is awesome, but worthless, if others don‘t follow. Well all the major browsers are on board—it’s really in the hands of the dev/product community now. Ok, i thought that only Apple uses biometric ID. Then: it‘s just awesome. Some people, who are not me, say that it's still two because they have to have the device but also have to be able to unlock the device. That makes sense (as long as device asks for PIN every time you use webauthn). Bank card uses the same logic: you present both card and PIN code and it counts as two factors. I have heard arguments that using a password locked ssh key is two factor authentication for the same reason, that is, what you have(the ssh key) and what you know(the password to unlock it) However I am not convinced, I think it comes down to dependency of factors in the auth scheme, if one factor unlocks another factor there only really is one factor, all factors must independently lock. The "something you have" shouldn't be easily replicated. If someone could capture your SSH key passphrase and copy the ssh private key then it's not an actual 2FA. a device like a Yubikey won't let you extract the stored keys, so the only way to gain access is to steal the physical key and that makes the attack much harder to do stealthily. Devices get snatched out of hands all the time. Even if they snatch it unlocked they still can’t login because there’s an extra biometrics check required for WebAuthn In at least Apple's case, Device PIN is also a factor to unlock the secure enclave where the passkeys are kept - so, assuming there's no stronger enforcement that it must use FaceID/TouchID, shoulder surfing a PIN unlock of the device and then swiping it grants access to all accounts. WebAuthn to either a a hardware key protected by a pin, or to a passkey protected by a biometric. Both definitely qualify as 2FA But there is no password, so we are back to 1FA, with Passkey being the single factor. This is similar to using password manager, with the exception that malware cannot steal your keys ... however, if it's able to steal passwords from password manager, there is a good chance that malware can also access your browser's cookies. It is still 2FA. Something you have (passkey on a device) and something you are (LIDAR map of your face and pulse). I currently authenticate with my fingerprint to 1Password, which then autofills a random password and an OTP code. That fulfils my security needs, and I'm unwilling to migrate to something harder to use. Nearly everyone I know has less tolerance for annoying security than me, so I don't see how WebAuth can possibly succeed. It’s not that bad to implement, especially since there are a lot of OSS libraries. The problem IMO is that it will, for most use cases, unconditionally authenticate you to a browser, not a physical token. And that will confuse a lot of people (and make some security engineers twitch). Why not a token? Lets be frank, pretty much nobody has a yubikey style token, and getting average users to use their phone as a token over Bluetooth is a recipe for support apocalypse. For bonus adoption friction, IT has trained a generation or two of users to not click on anything that could possibly compromise a computer. And webauthn requires actions often associated with granting permissions to your computer (Touch ID, Bluetooth access, plugging something into usb, etc). Passkeys are deliberately designed to avoid the issues with Bluetooth pairing. This is why a QR code needs to be scanned - devices do not need to be paired. Not all browsers do passkeys. When I visit https://webauthn.io/ using Chrome on my mac laptop, it pops up a bluetooth connection. Firefox asks me to connect a device or cancel. On Windows, Chrome and Edge gives me a QR code. Firefox triggers a Windows security popup. Inconsistency is the only constant so far. true that's yet another big problem I see with this: The user is prompted to enter his OS PIN/password/biometrics to random websites. He just has to trust that the popup wasn't faked and that his OS password isn't somehow transmitted to the website owner. That's a lot of trust to give to some random website. Precisely because the user won't see it as a OS trusted workflow, he sees it as a website that somehow made a Windows login pop up. He probably sees OS popups asking him to install something or allow notifications every few hours and they are rarely legitimate. Now suddenly this new popup is totally legit? Tough sell. They should have just created this around client certificates like another poster said and then the browser lets people pick and save the certificates to disk and now every user understands that websites will ask for his certificate files and that's okay because those aren't his real OS login. I don’t know the answer, but this is a pet peeve of mine. It’s especially frustrating when sites won’t let you enroll for 2FA with a hardware token. Instead they require that you start with some crap “authenticator” app first. Looking at you here, Gitlab and ProtonMail. I believe Gitlab has supported hardware keys for years now. At least Gitlab.com, not sure about the self hosted one. Also Protonmail supports both U2F and FIDO2. Introduced october last year [0]. Yes, but in order to enable it, they require that you enable an app first. I can only assume that this tactic is usually an attempt to maybe get your phone number, depending on which phone-based method you choose. Which is especially weird for ProtonMail. It does not require a phone number. Fwiw, Gitea now supports WebAuthn! It doesn’t provide any benefit to site operators. There are no punishments, drawbacks, or sticks to prevent web operators from shrugging off and ignoring WebAuthn in favor of implementing the bargain basement choice, user/password. Sign in with WebAuthn via hardware touch sensors is incredibly effective, but is also not an option for a considerable fraction of each site’s users. So it’ll always have to be a second method, not a first, and it comes with privacy hindrances for the greedy (think: Apple Private Relay integrated UI). Browsers would need to start presenting security warnings for classical password autofill to push adoption to the next level. Eventually the goal would be to remove username & password altogether. That would be MUCH simpler for developers. No email integration for forgot password flows, no need to hash and store credentials, etc. WebAuthn is dramatically easier to implement than passwords. What will folks accessing sites at a library do? They can’t access their cloud account, it’s a library computer. Spin up a VM to use ? I use it everywhere I can for the stuff I host. With how even banks rely on SMS for 2FA these days, I think this stuff just isn't on most companies' radars. It adds some convenience but until whoever is in charge of setting out a road map is convinced this is useful or something users may want, there's little benefit to spending the dev time. I use my phone for this stuff because Linux doesn't really support this stuff without faffing about with command line stuff and these keys are quite expensive (especially considering you need two to be safe). It's a shame, really. I'm honestly considering changing banks because my bank only supports SMS 2FA, and it triggers for every login. They need to at least adopt old school TOTP. In 2023, relying on SMS feels irresponsible for a side project let alone a bank. I noticed a couple of weeks ago that First Technology FCU allows using a TOTP second factor and deleting the mobile number entirely. Due to this, I'm in the process of changing over all of my regular banking stuff to them right now. (They are also the only remaining US issuer of proper chip-and-PIN payment cards, so far as I know.) Authentication is one thing. When it comes to banking - the authorization is the key (no pun intended ;)
Believe it or not, SMS is still one of the best ways to authorize sensitive transactions, even when compared to other popular options like TOTP or FIDO. The cool thing about SMS is that it gives you more context about what you're authorizing, so you're not blindly accepting requests from the bank without understanding what they're for. It's not perfect, but it's still pretty handy I hear you, but the not so cool thing about SMS is how trivially easy it is to clone a SIM. My level of trust for information passing through the SMS channel is near-zero. You're absolutely right - SIM swapping is a major threat in many parts of the world. If you're a target and the attacker is determined, you could be in serious trouble. However, it's more cost-effective for bad guys to launch phishing campaigns using malicious proxies like Evilginx or Modlishka to target the masses. I'm currently looking into deploying hardware keys for some of our users at work (mostly through Microsoft SSO which is FIDO2 passwordless), and one of the roadblock on our end is the inability to define our own minimum requirements for the PIN. Educating our users about the importance of using a secure PIN is indeed a priority, but it would be nice from a security standpoint of we could enforce some policies on our end to at least eliminate the possibility of settings some obviously weak PIN (0000, 1234, etc) > it would be nice from a security standpoint of we could enforce some policies on our end to at least eliminate the possibility of settings some obviously weak PIN (0000, 1234, etc) If your security model requires you retaining that level of control over your user's device security, MDM seems like the only option. > control over your user's device security, MDM seems like the only option. I hope that both the person to whom you are replying and their users and bosses remember that once someone has that level of control, it's not really that user's device any more. Where I work, we debated this sort of setup, but rejected it in favor of NFC Yubikeys largely on privacy grounds. We had several employees (doctors and nurses among them, since we are a medical practice) object to a device management profile, especially because of the remote wipe permission. Instead, we adopted Yubikeys and an automated provisioning process with a break-glass procedure if someone gets locked out. Why do you require a pin at all? The point of hardware keys is to protect against online takeover. Physical access is usually game over either way Because Microsoft's implementation is incredibly boneheaded, and doesn't allow the Google-style mechanism of username+password+Yubikey. They only support U2F/Webauthn as an alternative to a password. I assume Microsoft is hoping to make Windows the main Webauthn provider out there, to tie online identities into the Windows login process for easier tracking/advertising. Also - thanks to that FIDO2 does not seem to be usable with Microsoft's MS365 services [ Teams, Outlook, Excel etc ] on Android or iOS. there's no way to provide pin for the security key, regardless if it's plugged in via the USB port or used via NFC. https://learn.microsoft.com/en-us/azure/active-directory/aut... bummer 2 factors - something you know and something you have. The device is what you have, the pin is something you know, otherwise anyone can pick up your security key and use it Since Microsoft's implementation of FIDO2 is passwordless, you NEED to use a PIN, which is the "something you know" part, the key being "something you have". And if the PIN is complex enough, bruteforcing or guessing won't work as I believe the default behavior is to wipe the secure element storage after 8 incorrect attempts (with 3 attempts per key being initialized at a time). Those bruteforce protections aren't really worth a lot in practice. If you have physical access to the device, you will eventually be able to find a way to glitch it - as things like Cellebrite have already proven for the iPhone. Is there any demonstrated case where someone was able to exfiltrate secrets from a Yubikey secure element? It adds another factor (something you know), which increases the difficulty of an exploit. I've been working on a passkey-/WebAuth-first startup for the past months and I fully agree with most of the opinions for the slow adoption so far. From my experience, it's all comes down to two major obstacles: A) process / product flows and B) technical implementation. A) Passkeys / WebAuthn require a completely different user behavior (compared to passwords which everyone is familiar with) and thus a lot of user education. Many product managers see the benefits with less friction, but are super cautious to introduce passkeys for existing systems, especially when users are not too tech-savvy (if you're building a new system for a technical audience, then things look different). Besides it's a huge product management effort to cover all cross-devices/-browser/-platform flows and all edge cases that are involved. Due to the device-boundness of passkeys and the different UI patterns on different device/browser/platform combinations, it gets quickly complicated. Besides you still have to support all your existing login methods: passwords, MFA, social login, SSO. So many product managers looked for larger companies to show best practices for passkey / WebAuthn flows, but so far there's just a handful of these companies, so product managers rather wait for broader adoption. B) When talking to developers, many have heard of WebAuthn or the FIDO alliance, but integrating passkeys into your existing auth flow is not a 60 minutes task. You have to maintain your own WebAuthn server, deal with different forms of recovery and have to stitch everything together with the existing accounts & login methods. So far there's not many providers who offer easy WebAuthn / passkeys out-of-the-box and many like FusionAuth or Auth0 charge quite a lot for it. Moreover, passkeys / WebAuthn authentication is not anymore a backend-focused form of authentication, but a lot more frontend-loaded, as the UX plays quite an important role and the WebAuthn flow requires JavaScript to call the OS-native APIs. This makes things way more complex than just calling an email-password-auth endpoint. Besides, passkey implementations for native apps (Swift, Kotlin, Flutter) are very basic and good documentation for cross-device flows is lacking here as well. Nevertheless, there's a lot in the work under the hood and I'm still bullish that things will look pretty different in the near future. I've asked about it at FOSDEM this year but please when your software supports webauthn ask for the following factor in order: 1/ login 2/ webauthn 3/ password. This way webauthn will catch phishing site before you loose your password... It’s easy to implement, the reason it’s not more popular is because services are including support for other 2FA options, and users pick the path of least resistance. I wrote about this here https://blog.mailpace.com/blog/why-we-use-webauthn-for-2fa/ In short, we should implement webauthn, and only webauthn for 2FA Portability is still an unsolved problem, no matter how often FIDO Advocates say that it's solved (no 1Password is not actually portable, migration still isn't built into the spec as far as I can tell). I'm always happy to be proven wrong with this. Let me know if I can today (not maybe in the future, but right now) pull down an Open Source codebase onto my Linux computer, compile it myself without submitting some kind of validation check to a 3rd-party that will sign the code, and then batch export from an iPhone/iCloud account into that program so I can use it as provider without individually signing into any of those accounts. If not, then it's not portable. And that's why people (at the very least people like me) aren't using it, because it's transparently an opportunity to increase vendor lock-in and to allow services to dictate that I can only log into previously client-agnostic accounts using a small set of proprietary platforms. I know that's not the intention of the FIDO Alliance, but their intention doesn't matter if the end result is the same. Passwords do legitimately have a ton of problems and there is a theoretical version of Passkeys that would be amazing that I would be praising if it existed today. It's not that the idea is bad, there are changes to the standard that could be made that would make this good -- some of them would be controversial, some of them would make security purists upset. We'd need to have a conversation about what hardware attestation is actually going to be used for on a mass-market. But it could happen, it's not that passkeys are inherently bad. But you will have to drag me kicking and screaming away from a format that is client-agnostic and inherently portable into an authentication mechanism that trivially enables vendor lock-in. Don't tell me about what companies might do in the future, the companies launched products in the present that don't support migration. Fix that, and then I'll listen to conversations about how Passkey/WebAuthn is better. I never saw that thing. How does it work? For example I have Linux, Windows, iOS, Android devices and I want to use single HN account on those devices. How do I do that? I think that anything other than email+password will confuse users and probably not worth to implement. https://learn.microsoft.com/en-us/windows/security/identity-... Exciting that another one of my tech dreams is coming true! HN gets a public key, that's the account. The private key is stored on your device, say on iOS it would be stored encrypted in the secure enclave and accessible via TouchID/FaceID. There is little to no point in stealing the HN user database at that point because that's all just useless public keys, it has no passwords. If you wanted to add a device to the HN account you'd login, go to the settings, and generate another pub/private key for the new device rather than the traditional "change password". As there is no password. Most likely you're familiar with a variation of this already from sites like Github. > If you wanted to add a device to the HN account you'd login, go to the settings, and generate another pub/private key for the new device rather than [..] So I'm on my phone wanting to log into HN, and you're saying I need to go to my desktop (which is already logged in) to generate a key ... for the phone to be able to log in? Umm, I'm not sure Joe Q. Public is going to view that as acceptible. It's basically impossible to answer that hypothetical right now, because it depends entirely on the choice of client software. And that's still something that's evolving; it's just that Apple/Google/MS have the most prominent implementations here. If you have an iPhone and a Mac? No, your iPhone will log in via iCloud keychain. You use touchid/faceid to auth as usual. If you have an Android phone and a Chromebook/use Chrome? No, it will get sync'd implicitly. You use whatever the equivalent of touchid/faceid is to auth, as usual. If you're using some third party, pure-software, syncing solution? No, probably not. For example, existing password managers will probably just store the key material, encrypt it, then sync across devices. Again, pure software solution. You use 1Password on Windows 11 and also on your iPhone? You'll probably be fine. (Note: this is hypothetical, because 1Pass doesn't support it yet, but this is probably how it will shake out.) If you want to login with your Chromebook using a key it has generated and not export/sync the key, and you also have an iPhone at the same time you want to login with? Yes, you will need multiple keys, one for each device, and you will need to provision them. Realistically this is also a change to login flows on the server as well, so there's work to be done for the UX. For example many server-side auth packages are still adopting Passkeys into their flow, they need to change their schemas and frontends. One change to explore e.x. is you can ask the user after registering with WebAuthn is to register other devices, if they have them. Whether or not that's a workable solution remains to be seen. > [..] so there's work to be done [..] OK, we agree that much is clear :) Sorry if it wasn't clear: If you logged in to HN using Safari on a Mac the private-key (a.k.a "password") got chucked into your keychain as part of the account creation flow and is synced across all your iCloud devices. So on your phone when visiting the HN login page you'd just be prompted for a fingerprint by TouchID and in you go. Actually quite seamless. This would be what 90%+ of users experience as normal people don't fiddle with defaults. I don't use Windows but they have some sort of iCloud Passwords thing for Windows now too apparently. Just dipping their toe into slowly making it cross platform. It becomes less seamless and more of a hassle when you are using multiple keychains or 3rd party apps which probably a lot of people here are. What I described is that case, when you have both an Android phone and an iPhone and they are completely sequestered from each other (maybe personal and work?). > normal people don't fiddle with defaults Just to clarify, these "normal people", they are the ones who typically click on links in phishing emails without actually thinking? > an Android phone and an iPhone and they are completely sequestered from each other Q: Why would one not expect to have devices sequestered from each other? Anyway, umm, OK. Sounds like this "solution" means normal people are fine, anyone who isn't normal has a new mountain to climb. > Just to clarify, these "normal people", they are the ones who typically click on links in phishing emails without actually thinking? Yes? Heh, you know what normal people means, good. Guess what, phishing emails tricking people into visiting fake websites won't be as effective as with this flow there is no password for them to type in and accidentally give away to the attacker. > Q: Why would one not expect to have devices sequestered from each other? Because most people don't carry two phones or bother sequestering devices. It isn't the common case so it isn't a polished flow. At least not yet. Don't know about a mountain as you probably use a password manager already, it isn't much different. > If you wanted to add a device to the HN account you'd login, go to the settings, and generate another pub/private key for the new device rather than the traditional "change password". I still don't understand how do I do that. Let's say I registered account using iPhone. Now I want to log in with my Linux workstation. So I pick up iPhone, go to the https://news.ycombinator.com/settings click "Add device" and then what? I guess something like "recover password" workflow? Like I type my e-mail on new device, receive login link and then via login link I can register new device? This depends on the implementation. If you are in Apple world, your keys are synced between iOS and macOS (and saved in Secure Enclave, so you need TouchID/FaceID to complete flow.) In 'Google' world, you can use them between Android devices and Chrome browser. However, if you access from unsupported app/device (e.g. use Apple Passkeys and want to access from browser on Linux machine), you can always just scan QR code with phone, and use it to log-in. You can try it on https://www.passkeys.io you can try here too https://passkeys.guru/ > The private key is stored on your device, say on iOS it would be stored encrypted in the secure enclave and accessible via TouchID/FaceID. What's important is that even though they are stored in the SE, they are no longer tied to the device and can be exported. Prior to the introduction of passkeys, all FIDO-based keys were minted inside the SE, without the option of being exported. What does WebAuthn on Firefox on Linux look like? I got the impression it was impossible to use without a blessed bigco device and browser. You can use it with Chromium on Linux, but there's two parts to WebAuthn: the user-agent, and the client device/software that holds the key. So, WebAuthn shows you a QR code which you can scan. That happens on the user agent when you try to log in. It's no different than Windows. But the client software is a bit different. The client software scans the QR code and then provides proof you're the user you claim to be (normal pubkey cryptography) and then the user-agent and server do the rest of the dance. You can look at the spec, I can't remember all the details. But then the question is, what client software do you use? Most people use their phone for this part. The Phone scans the QR code. There's an implementation advantage for most phones: they can put the key in cryptographic storage on the device; this is one thing most bog-standard PCs are behind on (except Apple with the Secure Enclave, which was inherited from iPhones.) But again, there's no need for the crypto storage here. That's an implementation detail. Again, it just needs to scan the QR code and provide the proof. How that happens is totally arbitrary. So in theory you can use any software that can just scan a QR code and abide by the spec, for the second part. You could write your own code to store the keys in your GPG keychain, or whatever. But in practice, phones have the most mature implementation today. Most people use phones. They're the most robust and portable solution for most people right now. Presumably "sometime soon" things like 1Password, BitWarden, KeePass, and all those others -- their software will support scanning the QR code and then providing proofs. They'll sync your encrypted database or whatever too instead of using a hardware crypto enclave, but again: implementation details. So there's nothing about "blessed devices" here or whatever. I think in practice it's just that this is all relatively detailed and security sensitive components, both the user-agent and client software. So those companies are in the best place to implement all that shit. They also tend to have the advantage of their moat; it's easy to onboard Android users via Chrome or Apple users via Safari. It's relatively new, and so the demand for alternative software solutions hasn't reached any critical mass, either. Also: all of this change the login model a bit, so you need to be able to e.g. associate multiple keys with one account. That's a server-side thing; maybe you need a schema change for example. There's some effort to be spent here by all parties. Firefox does not support Passkeys at the moment on Linux. Chrome and Chromium do, I believe. You could possibly hack some shell scripts to read a QR code from a screenshot and then put/retrieve the key from `pass` or whatever. Thank you for the explainer. From a lot of what I read it seemed like you had to use an Apple/Google/MS keychain but I'm glad that's not the case. Looking for early feedback on AuthCompanion - a webauthn server (w/ JWTs) to make integrating user authentication with your web apps simpler. I think it's because it's a pain to have one key per device. To solve this, you'd need a service like iCloud Keychain (for Apple devices), but that only works for Safari and other Apple stuff. I think once 3rd party apps (like 1Password - see https://www.future.1password.com/) start supporting the syncing of keys, you'll see more use. Alternatively, if you could use iCloud Keychain with Chrome and Firefox, maybe that would work, too. Looking forward to this future! The whole point of a FIDO2 USB key is that the secret in it cannot be copied. If it can be copied any malware will just copy it and done. One possibility for WebAuthn over email/password is the easy retrieval of local, strong and domain-unique encryption key material via the prf extension. Support for this is currently limited to Chrome Canary + hardware key, but MasterKale thinks it will be coming to other browsers, and biometric: https://blog.millerti.me/2023/01/22/encrypting-data-in-the-b... One downside is that it requires Javascript. They made it too secure. Classic overengineering. The hardware aspect should have been optional from the start. It needed two things: browser free credential management that didn't need special hardware and a way to move around creds between devices effortlessly. The security improvements are great but outside of people who care a lot about this (similar to fido2) it makes things more difficult without making other things less difficult. Because it's a pain for normies and the UX defense from advocates is "something must be done, this is something, therefore we must do it". Please, if you back with Ally bank, email them and tell them you want Webauthn, not SMS. Ask to have the email forwarded to the head of development. Please and thank you. What about the transactions authorization? Use the mobile app as the channel for any additional confirmation. Oh, got ya. In that case it's even better to use the same app for authentication. I though mobile app was not an option for that bank. Doesn't WebAuthn require a Trusted Platform Module or an equivalent hardware solution, like trusted execution environments, for storing keys? This varies across hardware platforms and vendors which why I'm guessing solutions like WebAuthn haven't become ubiquitous yet. Its a per browser implementation decision, not required by the protocol. Chrome family browsers even ship a pure SW one but it's in the dev tools side. I was basing that on what I've read so far about WebAuthn. How does Chrome handle key management? For example this is what the Wikipedia article says: On the client side, support for WebAuthn can be implemented in a variety of ways. The underlying cryptographic operations are performed by an authenticator, which is an abstract functional model that is mostly agnostic with respect to how the key material is managed. This makes it possible to implement support for WebAuthn purely in software, making use of a processor's trusted execution environment or a Trusted Platform Module (TPM). Let's see how perfect it is when you need to switch devices or operating systems. Personally I wont use it as Long as I cant store my keys in my own password manager. I don't use stock android, windows or iOS, and I'm sure as hell don't want to be locked to one of them if I did. We use it at work and for whatever reason every time I get it working one one device, it stops working on another. That and it seems to be fragile across the VPN. "the" VPN? I'd be interested to know which proprietary vendor you're referring to. Can you use WebAuthn when you're in nested RDP sessions? Nobody wants this, it's a big pain in the ass.