There are some hairy edge cases during registration that many get wrong. (At least GitHub and google had this bug) that if create() returns but the passkey never reaches the server due to bad networking conditions that your password manager thinks it can log in but the server never recorded the passkey for the user. Basically there is no transactionality and you can get in a split brain situation where your password manager and your server don't agree and it's very confusing for end users.
now just 27 absurdly insane implementation hacks to solve.
webauthn is the only spec born like a 60 yr old legacy technology with global adoption. everything about it is insane.
they didn't even think about having more than one key plugged in (mostly because the use case was just so that the device own your identity so they never thought the use would have control over the hardware), and the solution is to just blink all the keys and use the first one the use touches while hoping the other keys with timeout before the use actually have to use them. so much insanity.
This is an excellent write-up that finally motivated me to try to understand the mess that was left behind as new standards kept being layered on top of each other.
Given the requirement for discoverable credentials and sync, truly open/independent passkey implementations seem impossible/impractical. For example, you couldn't just have a set of Trezor-style devices that you load with the same seed and use that as your passkey without syncing the "discoverable" part of the credentials through some kind of cloud service. (The cloud service wouldn't need to be trusted with the actual keys, but you couldn't operate without it.)
As a result, it looks like you can essentially choose which ecosystem you want to lock yourself into...
With authenticatorAttachment, sites have been given a convenient foot-gun to make sure no single setup actually works for all sites, and with both the discoverable and non-discoverable credentials supported, inconsistency in the login flow for maximum confusion is guaranteed.
Add to it that this is like the 4th or 5th iteration of a standard in the field in about 10 years, and there's endless opportunity to get locked out because providers migrated from one standard (or buggy implementation) to another, or start setting things up only for the 6th standard to obsolete what you had (again, potentially locking you out).
And then people are surprised that users stick with passwords.
There is no technical requirement for discoverable credentials in most scenarios.
Sure, not having to type your username is nice, but I'll gladly still do that if it allows "passphrase-based paper-restore-able authenticators" such as the one you describe. (I have one of these, in fact!)
Many services I use that do support WebAuthN allow either variant to be used (i.e. they'll prefer discoverable credentials but will work just fine with non-discoverable ones), and arguably that should be how almost everybody ought to implement it.
Unfortunately, at least as many other services completely botch it, e.g. by making discoverable credentials mandatory, by allowlisting browsers (e.g. Paypal), allowlisting authenticators (e.g. my government's e-signature platform), or by using them in a functionally braindead way (e.g. Amazon, who for completely unfathomable reasons still requires TOTP behind WebAuthn, i.e. they replace the password with it, not the second factor).
So far I haven't noticed a strong trend towards enforcing discoverable credentials, but let's please name and shame everybody doing that. It's completely unnecessary.
> Many services I use that do support WebAuthN allow either variant
The problem with "many" is that unless it's 100% of the ones someone cares about, the solution can't really solve the problem, adding an additional pain in the ass and making it easier to just stick with passwords.
Sometimes, a lack of choices is a feature. (Compare e.g.: IPSec vs. Wireguard).
Even the closed-system solution pose problems. I think it didn't get much airtime, but when Chrome switched their approach to save passwords, a lot of users lost access to their accounts. A case where a feature wasn't sensibly discontinued.
The workaround now isn't using passkeys, something few people understand. Instead most seem to be migrating to an external password managers. Honestly, I don't have many arguments against this as these at least generate save passwords. There are many advantages to this approach.
I believe moving forward, sticking to passwords might indeed be more viable. I think explaining users to upload their public ssl key is safer and more universal at this point.
I use password as main auth method for everything (via a pw manager) - but then I often add passkey or similar for convenience.
If I get locked out I still have the trad method as fallback; for me that’s the best of both worlds.
If you don’t offer password as method I will not use your service.
The worst are those that only offer code via email/sms or social login - miss me with that …
To me, they're an annoying half-measure: Not phishing/MITM resistant, yet annoying to use in practice.
I'll still take them over SMS-OTP any day, but admittedly even that at least offers some technical benefits over TOTP, e.g. in that the relying party can tell me what I am consenting to in the message ("by entering this code, you approve a payment of $1000 to evilshop.com").
2 factor authentication using 2 simple mechanisms is great.
Password for most cases. And then in high value things, ask me for 2FA. For things like banks and anything money related, SMS 2FA already exists and is good enough. For normal websites, uncommon yet important actions, such as logging in (everyone can use long lived sessions these days), repo deletion on GitHub, etc, ask for me for 2FA.
TOTP is also a really nice mechanism, especially in authenticator apps today that can backup your keys to cloud storage.
I know "SMS" and "backup keys to cloud storage" gets the security folks off their chairs, but outside a theoretical setting they're both a perfectly good tradeoff.
Hard, hard disagree. They’re really not. Password reuse is rubbish. Passwords human beings can remember are rubbish. But a secure password — i.e., a random value with 128 bits of entropy (such as a random 28-letter string) known only to the two parties to an authentication — is not rubbish.
There is the very minimum amount of protocol necessary: one party asks for it; the other party provides it.
The end user can pick his own software to manage his passwords, or none at all (a piece of paper in a wallet is remarkably secure) and the relying party to has no ability to approve or disapprove.
I do agree that WebAuthn offers very real improvements over passwords (principally due to no longer being a shared secret), but it makes things worse for the users in a few ways. For one, the ability of relying parties to blacklist or whitelist authenticators tramples on the user’s freedom to use the software he wants. Attestation keys and enterprise attestation are user-hostile: users and servers are no longer equal parties.
And finally, the user experience of passkeys with, say, a phone-based authenticator is miserable: one must interrupt one’s computer usage, pick up the phone, unlock the phone, open the notification and unlock the app, then put the phone down.
All in all, while WebAuthn does offer real advantages, I am concerned by how it reduces users to mere consumers, digital serfs to their technological overlords.
> But a secure password — i.e., a random value with 128 bits of entropy (such as a random 28-letter string) known only to the two parties to an authentication — is not rubbish.
No, they're still rubbish. Even if you make them 256 bit, passwords are bearer tokens which are reused across multiple authentications, which makes them replayable (if intercepted on the client, in transit, or server-side), phishable, social engineerable etc.
> There is the very minimum amount of protocol necessary: one party asks for it; the other party provides it.
And that's unfortunately too little protocol to be secure for repeated authentications.
> [...] principally due to no longer being a shared secret [...]
No, that's not the most important part of WebAuthN. You could get most of the benefits, i.e. phishing and social engineering resistance, from running it as a symmetric encryption protocol as well. Asymmetric keys "only" make server-side storage less sensitive (in the same way that hashing does for regular passwords).
> The end user can pick his own software to manage his passwords, or none at all (a piece of paper in a wallet is remarkably secure) and the relying party to has no ability to approve or disapprove.
The same is true for WebAuthN! (The only counterpoint here is attestation, but that is no longer a thing ever since Apple and Google introduced cloud synchronization for their credentials.) The difference is that you now need at least some software, because the calculations are too difficult to do on pen and paper.
> I am concerned by how it reduces users to mere consumers, digital serfs to their technological overlords.
Then... just don't do that! There are several open source implementations FIDO for you to choose from at this point.
The assumption that only one party knows the password is not always (maybe even usually) incorrect. Plenty of sites store the password in plain text or hash on the server side. Meaning it's very possible for both parties to know it.
Looks like an amazing resource for webauthn. Currently diving into this so it comes at a nice time for me.
But it's also great advertising against WebAuthn. Hard to believe that this kind of complexity is needed, but as with OpenID Connect it feels like enterprise interests are running the ship, not end-users. Ease of implementation seems like a non-goal.
Just like every other piece on passkeys it does not justify them, at all.
Passwords have problems, but less than putting all authentication secrets in a single basket or ecosystem is (which is what big tech fundamentally wants).
Passkeys are a solution to a manufactured problem, and keeps getting pushed because it is a useful big tech honey trap that solidifies their user's captivity in their ecosystems.
KeePassXC has support. Many people use Vaultwarden. And so on.
Also, end users are already locked into Chrome and Safari (and Meta's webview and even worse fates).
Passkeys right now has upsides and downsides, like all technology.
I think they are both too complex/clunky on the data/spec/API side, and not complex enough on the UX/lifecycle side. But likely both will evolve based on the usage patterns that get solidified.
> KeePassXC has support. Many people use Vaultwarden. And so on.
It doesn’t matter if other authenticators could work if a relying party refuses to allow its users to use them.
> Also, end users are already locked into Chrome and Safari …
Not this end user; I am typing this in Firefox right now. Not coincidentally, WebAuthn is yet another bit of complexity making it slightly more difficult to implement a browser. From the perspective of the big tech companies, end users aren’t expected to write software, or to run anything the big tech companies haven vetted.
This is an extremely bad take. Webauthn and Passkeys do not necessitate handing over control to "big tech". They are standards implemented by open source projects as well as megacorps. Webauthn offers substantially better security than passwords, which we should all be moving away from by now.
Disclaimer; I work in security so my opinions are informed by actually knowing what I'm talking about.
It might provide more security but no, more security isn't the only metric when it comes to user facing stuff like this. If it was some implementation detail in a b2b service sure. But there are a lot more variables to take into account than just "how secure it is". As a trivial example, being able to recover an account is insecure by definition, yet is almost always necessary for any user created accounts.
Appeal to authority does not make a good argument.
We have witnessed the user capturing playbook of big tech for decades at this point. Ignoring what they are doing at this point is naive at best, malice at worst.
Much of the specs were created behind closed doors and never done in a way where we could have had outside input. They're completely corporate driven and designed to control users not empower them.
(nb. I'm not saying the folks were easy to work with or super open to discussion, but it was not some clandestine black kitchen where it was cooked up.)
The working group is definitely quite corporate-driven – just look at who's most active in it! – and has made some bad decisions in the past (my favorite example being [1], which effectively either breaks the hardware authenticator experience for passkeys or helps Yubico sell more/higher capacity Yubikeys, depending on how you look at it).
But I agree that one thing you can't accuse them of is not operating in the open. While I don't agree with some of their decisions, discussing feedback in Github issues as well as on public mailing lists is probably as transparent as it gets.
You're right that WebAuthn was much more public, but passkey was not.
I personally tried to stay apprised of passkey's development. After asking several developers and poking around the best I could, I was told several times that it was being primarily developed behind closed doors for corporate interests, invite-only, and wasn't ready for release. The only information available was the WebAuthn forums.
Even now the documentation is still poor, and there's essentially no rationale to understand design and architectural decisions. We're just given a spec and expected to adhere to it.
I've always wanted to write a serverless OIDC provider/SAML IdP but got stymied by the WebAuthn standards, which don't seem to be written for normal people. :( But this e-book looks like it might have enough actual code interleaved with exposition to serve as more than just a high-level intro.
Adam Langley is probably one of the most gifted teachers when it comes to explaining cryptography concepts. Very clear, concise, precise, and makes it simple enough for me to follow without getting my neurons all knotted up.
OIDC providers are surprisingly NOT complicated! I created one to implement single sign-on with AWS, and it ended up being only around 200 lines of code in Go. All you need to do is create a JSON blob that is signed by a public key that is known to the consumer of the IDP.
It interested me how quickly all of my auth methods started to include "pick the right one of three presented numbers" tests after TOTP got widespread. I'm guessing there is some replay method which they wanted to prevent? This is distinct from in protocol large random value challenges, it must be to ensure a Hooman, or very numerate dog is actually present.
TOTP codes are phishable and repayable in real-time - both via web (visiting the wrong site which asks for a TOTP and relays it within a few seconds), and via social engineering over the phone (give us one of the codes to prove it's you and we can keep your account safe).
Adding number matching or similar helps ensure that the same user is initiating the session as is approving it - an issue when people discovered that Microsoft (among others) would do push messages to authenticate a login, and that users (if spammed late at night with constant requests), would often eventually hit allow to stop the notifications.
Pick the right number is not secure (enough), unfortunately - MFA exhaustion leads to users hitting one of three at random in an attempt to "make the notifications stop" (that are, naturally, being spammed by the attacker with a password but no mfa).
The attacker just has to spam them a few dozen times to get the victim to pick the right one at random and let the attacker in.
This is why it's switched on good platforms to "type in the number you see", which mitigated this.
That's slightly better against people essentially accidentally letting attackers in, but still completely phishable by e.g. tech support scammers.
The big advantage of WebAuthN is that (at least for sane implementations, including all I've seen) there just is no way to enter an attacker-provided number and/or supply a displayed code to an attacker.
Readit News
https://github.com/w3c/webauthn/issues/2038
They apparently came up with a fix for this using something called Signals API but I don't think any browser implemented that yet.
Just wanted to highlight that this part of the UX is hairy and hard to get right
webauthn is the only spec born like a 60 yr old legacy technology with global adoption. everything about it is insane.
they didn't even think about having more than one key plugged in (mostly because the use case was just so that the device own your identity so they never thought the use would have control over the hardware), and the solution is to just blink all the keys and use the first one the use touches while hoping the other keys with timeout before the use actually have to use them. so much insanity.
Given the requirement for discoverable credentials and sync, truly open/independent passkey implementations seem impossible/impractical. For example, you couldn't just have a set of Trezor-style devices that you load with the same seed and use that as your passkey without syncing the "discoverable" part of the credentials through some kind of cloud service. (The cloud service wouldn't need to be trusted with the actual keys, but you couldn't operate without it.)
As a result, it looks like you can essentially choose which ecosystem you want to lock yourself into...
With authenticatorAttachment, sites have been given a convenient foot-gun to make sure no single setup actually works for all sites, and with both the discoverable and non-discoverable credentials supported, inconsistency in the login flow for maximum confusion is guaranteed.
Add to it that this is like the 4th or 5th iteration of a standard in the field in about 10 years, and there's endless opportunity to get locked out because providers migrated from one standard (or buggy implementation) to another, or start setting things up only for the 6th standard to obsolete what you had (again, potentially locking you out).
And then people are surprised that users stick with passwords.
Sure, not having to type your username is nice, but I'll gladly still do that if it allows "passphrase-based paper-restore-able authenticators" such as the one you describe. (I have one of these, in fact!)
Many services I use that do support WebAuthN allow either variant to be used (i.e. they'll prefer discoverable credentials but will work just fine with non-discoverable ones), and arguably that should be how almost everybody ought to implement it.
Unfortunately, at least as many other services completely botch it, e.g. by making discoverable credentials mandatory, by allowlisting browsers (e.g. Paypal), allowlisting authenticators (e.g. my government's e-signature platform), or by using them in a functionally braindead way (e.g. Amazon, who for completely unfathomable reasons still requires TOTP behind WebAuthn, i.e. they replace the password with it, not the second factor).
So far I haven't noticed a strong trend towards enforcing discoverable credentials, but let's please name and shame everybody doing that. It's completely unnecessary.
The problem with "many" is that unless it's 100% of the ones someone cares about, the solution can't really solve the problem, adding an additional pain in the ass and making it easier to just stick with passwords.
Sometimes, a lack of choices is a feature. (Compare e.g.: IPSec vs. Wireguard).
The workaround now isn't using passkeys, something few people understand. Instead most seem to be migrating to an external password managers. Honestly, I don't have many arguments against this as these at least generate save passwords. There are many advantages to this approach.
I believe moving forward, sticking to passwords might indeed be more viable. I think explaining users to upload their public ssl key is safer and more universal at this point.
If you don’t offer password as method I will not use your service. The worst are those that only offer code via email/sms or social login - miss me with that …
IMHO that and a TOTP seems to be a sweet spot.
I'll still take them over SMS-OTP any day, but admittedly even that at least offers some technical benefits over TOTP, e.g. in that the relying party can tell me what I am consenting to in the message ("by entering this code, you approve a payment of $1000 to evilshop.com").
2 factor authentication using 2 simple mechanisms is great.
Password for most cases. And then in high value things, ask me for 2FA. For things like banks and anything money related, SMS 2FA already exists and is good enough. For normal websites, uncommon yet important actions, such as logging in (everyone can use long lived sessions these days), repo deletion on GitHub, etc, ask for me for 2FA.
TOTP is also a really nice mechanism, especially in authenticator apps today that can backup your keys to cloud storage.
I know "SMS" and "backup keys to cloud storage" gets the security folks off their chairs, but outside a theoretical setting they're both a perfectly good tradeoff.
Deleted Comment
Deleted Comment
> Passwords are rubbish.
Hard, hard disagree. They’re really not. Password reuse is rubbish. Passwords human beings can remember are rubbish. But a secure password — i.e., a random value with 128 bits of entropy (such as a random 28-letter string) known only to the two parties to an authentication — is not rubbish.
There is the very minimum amount of protocol necessary: one party asks for it; the other party provides it.
The end user can pick his own software to manage his passwords, or none at all (a piece of paper in a wallet is remarkably secure) and the relying party to has no ability to approve or disapprove.
I do agree that WebAuthn offers very real improvements over passwords (principally due to no longer being a shared secret), but it makes things worse for the users in a few ways. For one, the ability of relying parties to blacklist or whitelist authenticators tramples on the user’s freedom to use the software he wants. Attestation keys and enterprise attestation are user-hostile: users and servers are no longer equal parties.
And finally, the user experience of passkeys with, say, a phone-based authenticator is miserable: one must interrupt one’s computer usage, pick up the phone, unlock the phone, open the notification and unlock the app, then put the phone down.
All in all, while WebAuthn does offer real advantages, I am concerned by how it reduces users to mere consumers, digital serfs to their technological overlords.
No, they're still rubbish. Even if you make them 256 bit, passwords are bearer tokens which are reused across multiple authentications, which makes them replayable (if intercepted on the client, in transit, or server-side), phishable, social engineerable etc.
> There is the very minimum amount of protocol necessary: one party asks for it; the other party provides it.
And that's unfortunately too little protocol to be secure for repeated authentications.
> [...] principally due to no longer being a shared secret [...]
No, that's not the most important part of WebAuthN. You could get most of the benefits, i.e. phishing and social engineering resistance, from running it as a symmetric encryption protocol as well. Asymmetric keys "only" make server-side storage less sensitive (in the same way that hashing does for regular passwords).
> The end user can pick his own software to manage his passwords, or none at all (a piece of paper in a wallet is remarkably secure) and the relying party to has no ability to approve or disapprove.
The same is true for WebAuthN! (The only counterpoint here is attestation, but that is no longer a thing ever since Apple and Google introduced cloud synchronization for their credentials.) The difference is that you now need at least some software, because the calculations are too difficult to do on pen and paper.
> I am concerned by how it reduces users to mere consumers, digital serfs to their technological overlords.
Then... just don't do that! There are several open source implementations FIDO for you to choose from at this point.
But it's also great advertising against WebAuthn. Hard to believe that this kind of complexity is needed, but as with OpenID Connect it feels like enterprise interests are running the ship, not end-users. Ease of implementation seems like a non-goal.
Passwords have problems, but less than putting all authentication secrets in a single basket or ecosystem is (which is what big tech fundamentally wants).
Passkeys are a solution to a manufactured problem, and keeps getting pushed because it is a useful big tech honey trap that solidifies their user's captivity in their ecosystems.
KeePassXC has support. Many people use Vaultwarden. And so on.
Also, end users are already locked into Chrome and Safari (and Meta's webview and even worse fates).
Passkeys right now has upsides and downsides, like all technology.
I think they are both too complex/clunky on the data/spec/API side, and not complex enough on the UX/lifecycle side. But likely both will evolve based on the usage patterns that get solidified.
It doesn’t matter if other authenticators could work if a relying party refuses to allow its users to use them.
> Also, end users are already locked into Chrome and Safari …
Not this end user; I am typing this in Firefox right now. Not coincidentally, WebAuthn is yet another bit of complexity making it slightly more difficult to implement a browser. From the perspective of the big tech companies, end users aren’t expected to write software, or to run anything the big tech companies haven vetted.
Disclaimer; I work in security so my opinions are informed by actually knowing what I'm talking about.
We have witnessed the user capturing playbook of big tech for decades at this point. Ignoring what they are doing at this point is naive at best, malice at worst.
Attestation enables a relying party to deny users the right of using their own software or devices. That hands over control.
WebAuthn? No, thanks.
Much of the specs were created behind closed doors and never done in a way where we could have had outside input. They're completely corporate driven and designed to control users not empower them.
https://lists.w3.org/Archives/Public/public-webauthn/
(nb. I'm not saying the folks were easy to work with or super open to discussion, but it was not some clandestine black kitchen where it was cooked up.)
But I agree that one thing you can't accuse them of is not operating in the open. While I don't agree with some of their decisions, discussing feedback in Github issues as well as on public mailing lists is probably as transparent as it gets.
[1] https://github.com/w3c/webauthn/issues/1822
I personally tried to stay apprised of passkey's development. After asking several developers and poking around the best I could, I was told several times that it was being primarily developed behind closed doors for corporate interests, invite-only, and wasn't ready for release. The only information available was the WebAuthn forums.
Even now the documentation is still poor, and there's essentially no rationale to understand design and architectural decisions. We're just given a spec and expected to adhere to it.
I'll need to do a write-up for it.
Adding number matching or similar helps ensure that the same user is initiating the session as is approving it - an issue when people discovered that Microsoft (among others) would do push messages to authenticate a login, and that users (if spammed late at night with constant requests), would often eventually hit allow to stop the notifications.
The attacker just has to spam them a few dozen times to get the victim to pick the right one at random and let the attacker in.
This is why it's switched on good platforms to "type in the number you see", which mitigated this.
The big advantage of WebAuthN is that (at least for sane implementations, including all I've seen) there just is no way to enter an attacker-provided number and/or supply a displayed code to an attacker.