In case you heard about Passkeys and WebAuthn, you might wonder what are the differences, or their relationship. This article tries to clarify what both are and shares some personal opinions about the implications of Passkeys.
What is WebAuthn?
WebAuthn is a specification. It is an "RFC" issued by W3C, standing for "Web Authentication" to specify a set of interfaces for browsers to implement.
How does it work?
Fundamentally, the protocol's concept is rather straightforward.
During registration, the device (called "authenticator") generates a cryptographic key pair. The public key is sent to the server and the private key is safely stored locally.
During authentication, the server then asks the client to sign a message with a nonce (called "challenge") with its private key pair. This signed message with the nonce can then be verified by the server using the public key obtained through registration.
Moreover, the private key was never exposed. The signing of the message is done directly by the "authenticator", the device, and protected by some form of local user verification (like fingerprint, face, local PIN, swipe pattern, etc).
This had really strong security properties because the private key was hardware bound, and needed user's local verification to access it.
Why did I use the past tense? Because of ...Passkeys!
What are Passkeys?
Passkeys is basically the platform's implementations of the WebAuthn. Until now, the protocol had a shortcoming: if the user lost their device, they lost the private key and were locked out of their accounts. Bam!
The websites and users would have to either let them register multiple devices, with an associated key pair each, or rely on a (possibly less secure) account recovery mechanism.
To circumvent that, Apple, Google and Microsoft decided to go forward with "Passkeys". This is basically nothing else than WebAuthn but they sync your private keys into the cloud. Your private keys are not tied to the device anymore, they are "backed up" in the cloud, as they say.
It's like handing over a copy of your keys to Apple/Google/Microsoft saying "Here are my keys guys, keep it safe!". This is both a boon and a curse. On one hand, the users don't have to worry about losing their keys. On the other hand, it has of course strong implications on security, privacy and vendor lock-in.
Security-wise, the attack surface becomes bigger: on the device level (since it goes in an out of the secure hardware key store), on the network level by intercepting the syncing mechanism, on the vendor level in case of data breach and on the recovery level with someone trying to impersonate you.
Privacy-wise, they have your keys. Whether it's for their purpose, because of the NSA or whatever agency, they could access all your private accounts. That's a question of thrust here that they don't do.
Regarding vendor lock-in, if they have all your keys and you want to switch the platform ...well, you got a problem. You would probably have to re-register or launch recovery procedures on most accounts. It's quite a pain, and more sneaky since it only becomes obvious once it's too late. If keys were not synced, websites would put more effort into supporting multiple keys per account, thus being cross-platform by default. But with Passkeys they'll likely prefer to let the platform handle it.
Passkeys in practice
The main issue is also that you cannot opt in or out. The WebAuthn protocol lets the platform dictate. It was also raised in this issue that this is problematic: reduced security guarantees, regulations that cannot be applied, no way to block insecure device models, etc... However, the spec is driven by the big player's implementations rather than the other way around.
The other issue is that, in reality, it turns out to be more complex for websites to deal with ...at least, if you want to do it properly. Before Passkeys, you just had to let the users register multiple devices or have sound recovery mechanisms. Now, websites have to deal with devices that are maybe synced, or maybe not, or maybe not yet. Perhaps the user used a hardware key, which is not synced, or disabled it somehow if the platform permits it, or simply hasn't synced the key yet. In other words, there are more cases to take into account while still needing the same safety measures to avoid that a device loss leads to account "lock-out".
Lastly, these security, privacy and vendor lock-in effects are not recognized by average users. They just want to sign in. It is our duty as developers to deal with these issues responsibly.
WebAuthn in practice
In practice, it's a mess. The specification is overly complicated, long, unclear and there is a clear gap between the specs and implementations.
For example, let me cite the second sentence of the abstract.
Conceptually, one or more public key credentials, each scoped to a given WebAuthn Relying Party, are created by and bound to authenticators as requested by the web application.
Well, it's simply not true anymore since mid-2021 and noted in an issue but the specs remains unchained until now.
So, the specs differ from implementations and every platform and browser will deliver you another experience... which is IMHO still seriously lacking. Moreover, "Open" Browsers like Firefox are struggling and lagging behind with partial implementations due to the complexity of the specs, Linux as well...
So, although it's great on paper, the practical experience is a hit-or-miss thing. As it stands now, I strongly recommend to offer an alternative sign in experience if WebAuthn isn't properly supported or if "it doesn't work properly" on the user's device.
Moreover, it's not for the faint of heart. As a developer, you will have to deal with ArrayBuffers using a CBOR encoding and lots of low-level things. The whole process is not simple either, for example, registration is described as a 26 step procedure and authentication requires 23 steps to verify. Have fun! (sarcastic tone)
Conclusion
In my humble opinion, WebAuthn is an awesome concept with terrible execution. The promise is to get vastly improved security and convenience in the same package. However, what you get is a spec that a normal person cannot read, incredible complexity for developers, and browser implementations that are sometimes not working as expected or with poor UX. So here goes your vastly improved security with the touch of a finger ...down the drain. It's just a lot of painful work to get it right properly.
Moreover, it feels like the "big players" move to Passkeys was mostly a hype attempt ...and to pursue their own agenda of user retention rather than being truly helpful to the developer community. They wanted a new start, to remove the hurdle of multiple keys per account and encourage adoption that way. However, it does this at the cost of security, privacy and lock-in, so while useful it is a steep price. Moreover, "rebranding" the struggling WebAuthn specs as Passkeys rather adds to the confusion while not resolving the core problems, namely the complexity of the protocol itself.
So what's my take on it? If you have sufficient resources and time to pour into this, yes, you should support WebAuthn/Passkeys. It is better security-wise and depending how it's implemented, it might be more convenient too. However, if you do not, use an existing authentication provider. Using OpenID/OAuth2 is really much simpler than WebAuthn. You can also combine both by using Passwordless.ID for example, it's a public free identity provider offering passwordless authentication using WebAuthn. Try it if you want.
Thanks for reading and feel free to share your opinion!
Top comments (13)
I'm having a hard time parsing the message here: WebAuthn is great, but it's a failure, but it's great, don't use it yourself, but use it at my own solution (that I'm apparently running solo, so wish me luck that I can maintain it forever). I feel a bit of bad faith in your article (for one, I didn't understand the "you cannot opt in or opt out" stance; maybe it's just me not understanding what you actually mean…)
One of the selling point of passkeys is that websites only need to jump in on passkeys and anyone can then use passkeys the way they want it: a Yubikey Bio, a Google account, an Apple account, Windows Hello, a Dashlane account, soon a 1Password account, and other similar secret managers, etc. Using OpenID Connect with a given service (like yours) means creating an account on that service: this in itself is an impediment. OIDC also means the IdP, that the website (RP) chose, not the user, knows every website the user has signed in, and this is a privacy concern.
And with passwordless-id, if you as a user don't take it seriously and register other devices with your account, or at a minimum a recovery option, then you're likely to be locked out. While I sympathize with your stance about passkeys, I don't think your approach using device-bound keys has a chance to get a large adoption, and that's what passkeys aim for. This is similar to when browser makers made it easy to generate unique passwords for websites by becoming password managers with cloud sync themselves: concentration isn't great, but at least more people will use password managers (and my wife and daughter would have never used a password manager if it hadn't been that seamlessly integrated, and I had to battle to make them use it rather than reusing the same few passwords everywhere). I had to setup 2FA myself on their accounts, using SMS because it's easier, and argue so they don't disable it.
So while passkeys are possibly not as good as device-bound keys (that's what I understand you're saying), they're still far better than passwords, and have a real chance of being widely adopted (not in the short term, there's still work needed IMO to make them more seamless, but hopefully soon).
Thanks for the detailed feedback. I'll try to respond the best I can.
Well, things are often not black or white. The same goes for that protocol. The concept is great, it was 2FA with a single touch and eliminates all the password related vulnerabilities. However, the execution was IMHO severely lacking, leading to an overcomplexified RFC which was challenging for developers. Lastly, last year's move to sync the private keys in the cloud by the big players transform this 2FA into "one and a half" FA.
First, due to the complexity of the protocol, secure usage is difficult. Authentication is going more and more in the direction of "rocket science" ;) However, that is not the main point. The main point is that as a "service provider" you do not know whether the passkey the user has is "synced" by the underlying platform or not. You will have to handle both cases, by for example letting the user register multiple devices and other recovery procedures, or still use passwords as alternative, which all adds up to the complexity.
Indeed. I'd love to run this a full time job and transform it in a foundation or whatever, but truth is that this is currently a personal project as you stated. Thus, so I totally understand the reluctance to use it. In the worst case you'd have to re-implement the login in the future.
Well, there is no bad faith, I assure you. What I meant by that sentence is that on protocol level, you cannot say "Dear device, please let this be a hardware bound key" (AFAIK, perhaps things evolved since I last checked) but the platform will decide wether it will sync this private key in the cloud.
As stated earlier, it's easier said than done. It requires effort and is by far more difficult than interfacing with an OpenID/OAuth2 provider.
I think things are mixed up here. A "passkey" is basically a private key on your device. This is either generated by the OS or a hardware piece. Password managers on the other hand have no access to the keys ...so they are actually quite limited in what they can do, other than rely on the OS's syncing capabilities which are there anyway. They are great at marketing though.
Agreed. Although I tried to make it as simple as possible, even the simplest version is a hurdle.
Indeed. One account where the IdP knows activity or 100 independent accounts for privacy. It's up to you. I'd say the tendency goes to centralized accounts though.
Indeed. That's why a big red banner is displayed in that case.
Well, I have no influence over the protocol. My point is that before WebAuthn was equivalent to "comfortable 2FA", while now it became something equivalent to "Sign in with Google/Microsoft/Apple" since access to the account (often) means access to the synced keys. But, as stated earlier, I have no influence over the syncing or not of the key since the protocol does not offer it (yet?).
Nevertheless, the issue that a key on your IPhone is not synced with your Windows laptop or your Android tablet remains. On another note, people will probably dislike registering multiple devices (one per platform) for each website using passkeys. Password managers won't solve it either since they have no access. This walled garden effect from platforms may become the right soil for Passwordless.ID.
I can totally relate to that. ;)
Yup.
Well, I'm not so sure. The effort required for each website to implement WebAuthn/Passkeys is quite substantial, and now that the benefit over "Sign in with X" is blured, I don't think adoption will boom.
I think webauthn will arrive at some point as the standard login for the platform (MS/Google/Apple) for enhanced security and ease of use. Some big brands or specific websites might too, but that's it.
Most webapps will keep "Sign in with ..." for simplicity and since it is security-wise almost equivalent to synced passkeys.
I don't get why it's "one and a half": you need both the keypair (which either means you have the device with device-bound passkey, or you sync'd the passkey to the device using some mean – not necessarily cloud-based) and user verification (which is not just user presence, but using a user-specific gesture: biometrics, PIN, unlock pattern, etc.)
You might have missed the announcements from Dashlane, 1Password, and Bitwarden then; and by Google that Android 14 will allow third-parties to handle passkeys just like it allows them handling passwords already (so using Dashlane, 1Password or Bitwarden on all of your devices to sync passkeys between devices). I'm expecting Apple to announce something similar for iOS 17 and macOS at the WWDC, and Microsoft is unexplicably late to the game.
Note: passkeys are not just WebAuthn, they're WebAuthn used in specific conditions with specific options.
What I meant is that before you had clear 2FA: hardware possession + user verification. With passkeys, it has become "get access to MS/Google/Apple account" since this could sync the keys on any device. Depending on security settings, even phishing a password might be enough to access it. It is as secure as the provider's account access (from a new device) ...which is often well secured, granted, but may also have weaknesses like guessing some security questions. It's simply not clear cut 2FA like before with hardware-bound keys.
I may have missed that. Do you have a link? I always thought that password managers could only trigger the webauthn/passkeys mechanism, but not access the private keys (hence no syncing). Exposing keys feels like weakening the protocol's security even further. :-/
Passkeys are: access to the private key on the device (sync through cloud account is the most convenient, but there are other ways) + user verification. Without user verification, that's not a passkey, just WebAuthn, and should then only be used for 2FA. See the how to FIDO FAQ for details on how to implement the best UX for that.
A Yubikey Bio can be used as device-bound passkey for example: hardware possession + biometric. Other kinds of security keys without biometric unlock (or similar) can only be used as 2FA becausee they lack user verification (touching/pressing the key is not enough, that's user presence, not user verification).
That's incorrect and misleading. WebAuthn has a property
userVerification, which is by defaultpreferredbut can be set torequired. On the other hand, PassKeys is just a rebranding of WebAuthn + syncing of keys. Even the link you provided solely shows a code sample on how to invoke the WebAuthn protocol.It does ...I guess such hardware keys are the only true 2FA left.
I'm also curious how the password managers manage the "passkeys", I mean, technically. Perhaps they register themeselves as "roaming" authenticators but instead of being physical they are purely software based... I wonder.
But these PassKeys touted as the most secure future became IMHO full of cracks with time.
The protocol is overly complex, the default optional user verification not the most secure, and now keys can be managed by third party software. Yay ...all the way from solid 2FA to a thin layer of ice. It's not like password managers haven't been hacked in the past.
passkeys.dev/docs/reference/terms/...
Wrt userVerification preferred vs required, see passkeys.dev/docs/use-cases/bootst...
PS: just to avoid misunderstandings, I don't wanna say that webauthn/passkeys and password managers are "bad". Of course it makes sense to use them and it's better than repeating the same simple password everywhere.
What I'm a bit disappointed is that the WebAuthn protocol (although complex) was 2FA by design and was softened to the point that keys are synced by thrid party software and recommendations do not enforce user verification. As such, the benefit over a plain "Sign in with XYZ" button is kind of non-existent.
Do you know for a fact that Google etc will be storing your passkeys unencrypted?
That sounds really unlikely - that's not how passwords are stored in the cloud today, they are encrypted by a master password.
I'd assume that's what they plan to do?
I personally wouldn't hand over my private keys to anybody.
I never said they are stored/transmitted unencrypted. That would be utterly irresponsible. However, the key is there, encrypted, with a way to be decrypted too, and I believe it's not a master password, otherwise people would be locked out when forgetting it. It is fundamentally different to passwords which are not encrypted but hashed. It's a one way process, you cannot "recover" a properly hashed password, only reset it. ...and I'm not a fan of having my passwords in the cloud either. So many password managers have been hacked in the past. My point is only that although the big techs probably do have strong "defenses" in place, syncing the passkeys is still a weakening of the protocol's security by design.
But we accept all of those limitations with password managers today. It's still way better than using either weak passwords you can remember, or using the same password everywhere. Nothing is perfect, I suppose?
That's why I think going passwordless with webauthn based solutions is the future. It's more secure and you don't have to remember anything. It's just a bit sad that they (google/microsoft/apple) made a perfectly secure protocol slighlty less secure. Before, it was true 2FA, now it's "I can connect to my main account ...which syncs my keys". They swapped security for comfort. This follows the trends of centralized accounts, with "sign in with... google/microsoft/apple". The only downside is that they don't play well together, that's why I introduced the concept of passwordless.id, a public identity provider to rule them all. Just kidding. It's meant to be easier to use though.
There is always a trade off between security and usability though, isn't there? They want this technology to go main stream - that means your mom and dad have to be able to understand and use it.
If tech nerds (or government types etc.) need something more secure, that's probably not this - but that's not really the audience it's designed for, and it likely wouldn't stand much of a chance in the wild if they prioritized security above everything else.
I think this needs to be something people actually can and will use.