In case you heard about Passkeys and WebAuthn, you might wonder what are the differences, or their relationship. This article tries to clarify what...
For further actions, you may consider blocking this person and/or reporting abuse
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.