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.
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.
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.
> 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.
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.
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.
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.
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.
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.
> 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.
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
(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.
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.
On Apple platforms, a biometric authentication is required to proceed with webauthn, so technically it is 2FA (something you have and something you are).
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.
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.
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.
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.
Readit News
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...
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.
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.
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.
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.
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.
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.
But that doesn't sound like something I'd ever want. Obviously I want to be able to log in on my computer too?
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.
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.
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.
> 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.
> 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.
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.
When I’m traveling and robbed, I won’t be able to get the backup device is hidden in my drawer at home
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.
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.
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:
https://github.com/heartcombo/devise/issues/5527
- "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
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.
Deleted Comment
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.
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.
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.
evilginx will happily steal most other 2FA (TOTP, ...).
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.
Deleted Comment
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.
Nearly everyone I know has less tolerance for annoying security than me, so I don't see how WebAuth can possibly succeed.
Deleted Comment
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).
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.
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.
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.
[0]: https://proton.me/blog/security-keys