The article author skirts around the key true observation here, which is that passkeys were a great idea until cloud vendors waged war on hardware keys.
The concept of a passkey as desired by Yubico was that every user buys a set of hardware keys, uses those instead of passwords, and has no ability to authenticate otherwise.
The concept of a passkey as desired by Apple, Google, and Microsoft is that every user magically authenticates using their OS, and has no ability to authenticate otherwise.
The reason the UX is confusing is because the OS vendors don't want the users using non-OS software or hardware - they want you to use a cloud-hosted passkey instead of using a Discoverable Credential on a Hardware Authenticator, and instead of using a password manager providing its own sync facility. This is shown in the screenshots in the article.
The ideal future state is:
* the provider for newly registered credentials would be a browser setting
* the setting would come configured to use the OS vendor out of the box
* installing a password manager providing passkeys would prompt to change the setting to use the password manager instead
* one of the options in this setting would be "prompt me every time". Approximately nobody would choose that option
* there would never be a prompt for what to use on authenticate() calls, only register(). Authenticate would use whichever valid credential you provided first, whether that's plugging in a token or scanning your thumb to unlock a TPM or whatever
In this world, 99% of people are using OS-vendor-provided cloud-synced passkeys, but technical users get what they want too and everybody has both a secure and an easy experience.
The thing stopping us from getting to that ideal state is that the provider of the FIDO "platform" (the software that lets you choose a key to use) is the OS vendor instead of the browser vendor, and they have a conflict of interest because the OS vendors are also cloud services vendors.
> passkeys were a great idea until cloud vendors waged war on hardware keys.
> The concept of a passkey as desired by Yubico was that every user buys a set of hardware keys, uses those instead of passwords, and has no ability to authenticate otherwise.
This was never a great idea, it was totally unworkable for nearly everyone. Physical keys work because locksmiths exist, keys can be copied, and users get to choose when they lock the door/box/whatever. And even with those benefits they're rapidly being replaced for a lot of people with PIN codes or mobile apps precisely because physical keys are suboptimal.
Hardware keys as envisioned here cannot be copied without registering the copy separately with each and every service, have no equivalent of locksmiths besides "store these 10 recovery codes somewhere safe" (also unworkable as a solution), and between session timeouts and multiple devices users are regularly unable to predict when and where they will need to create a new session.
Hardware keys were designed for a spherical humanity, not for the humanity that has to deal with ADHD, dementia, babies, kids, fires, floods, and a host of other failure modes. OS keys inherit many but not all of the flaws of hardware keys, but at least they don't rely on a human being responsible!
> And even with those benefits they're rapidly being replaced for a lot of people with PIN codes or mobile apps precisely because physical keys are suboptimal.
I would be careful with the use of "suboptimal" here. PIN codes or mobile apps are possibly more convenient to some people, not necessarily more secure (a PIN can leak, a smartphone can be hacked).
I would argue that hardware keys are optimal in the use-case they solve. It's just that not everybody wants to solve this use-case. And that's okay: passkeys should allow users to choose.
Yea, the physical key is, to me at least, one of the top human inventions.
Ubiquitous, cheap, convenient, and provides sufficient security. My little brass key never needs charging, never refuses to open the door because I didn't apply the latest over-the-air update, doesn't phone home to an advertising firm to track every time I open and close a door.
I can make as many copies as I like and give them to friends and family in case I lose mine. There are some scenarios where it might be nice to have a smart lock, but for me at least, they are so few and far between that I'll stick with this tiny bit of metal.
This is valid: use case matters. But almost no one has a use case for which hardware keys are optimal.
If you live in an area where you don't have bars on your windows, you don't gain more security from using a physical key over a PIN or app. (Even if you do have bars, the physical key is likely still suboptimal).
If you're a regular user of the kind of application where anyone ever thought passwords were a valid authentication solution, you don't benefit from a hardware key.
And it's not just a question of more security than necessary: using a security mechanism that is overkill for your needs can actually leave you with lower total security, because you'll end up doing things to make your life more convenient that are worse than what you'd have done with a weaker mechanism (like in the physical case leaving the door unlocked to avoid locking yourself out).
I guess my point is: "don't ignore your tech-savvy users".
And more generally, don't think that 99.9999% of your users are morons. In this case, all it costs is to leave an alternative in the list.
Too much of the modern software completely sucks because the industry is obsessed with "hiding complexity". We should not hide complexity, we should offer abstractions on top, and leave access to the lower-level as much as possible.
I think the passkeys would have remained a great idea if all passkeys were provided either by hardware devices not sold by cloud services vendors, or by software not written by OS vendors.
I largely agree with your point, and I don't think most users should be using hardware tokens. But the TPM chip in the user's phone should be usable by any app on that phone, not just by the OS vendor.
I stand by my original statement that the standard was fine until users started getting shoehorned into "use Google passkeys on your Android".
In the practical one we're living in, this would mean that almost no website would implement them, because almost no user would be capable of using them.
As much as I dislike the platform lock-in consequences, bootstrapping a two-sided network is incredibly hard and usually does not succeed without something aggressively pushed onto users (e.g. by preinstalling and preselecting it) to kickstart things. In the best case, this is then quickly replaced by user choice, and that's what has fortunately happened for passkeys.
> the TPM chip in the user's phone should be usable by any app on that phone, not just by the OS vendor.
Do you mean TPM as a generic term for a hardened secure element/enclave? Unfortunately, these are not standardized at this point (actual TPMs are, but these are a PC thing).
And what would be the point? I could see secure enclaves/elements implementing CTAP2 instead of a proprietary interface, but I don't really see the benefits of that. The much more important thing would be that all applications on the OS can access that implementation through some API, and that would reasonably be the "FIDO backend" APIs both iOS and Android already provide.
Mostly unrelated, I fondly remember Google doing one of those "prove you're you" checks when I was in a different state, allowing me to waste one of my 10 recovery codes as one of the options, and still refusing to let me log back in till I got back on my home WiFi a few weeks later.
I think a critical feature is missing that makes this almost entirely unworkable: usable handling of backup tokens. There is no way to register a token in a safe. There is no way to name a token to keep track of which one it is. There is no intelligent way to migrate from one token to a new one. Working with two computers with mutually incompatible ports is incredibly annoying.
NFC tokens have basically no security against a close range attacker. How much this matters depends on the threat model.
Also: the cloud vendor passkeys (Apple, Google, etc) are far more secure against an attacker that steals a device.
This is not to say that cloud based passkeys are amazing. AFAICT there is nothing remotely resembling an automated way to rotate a key. I’m not even convinced it can be done manually in a straightforward manner. This is not so great, given that a passkey is effectively an unlimited lifetime key pair with no revocation mechanism, that may well be stored without hardware security and that can be propagated to different generations of devices. Also, what happens if a device is stolen and compromised at least enough to keep its password manager running?
> NFC tokens have basically no security against a close range attacker. How much this matters depends on the threat model.
No, the CTAP standard (what FIDO is using for communication with NFC tokens) provides pretty good resistance against this threat. There's actually a diffie-helman key exchange between the computer (platform) and authenticator (token). The only way it could really be better is if it did challenge-response for your PIN authentication, but as it is if you eavesdrop a CTAP NFC exchange you do not get the user's PIN, or the ability to generate/use a credential later.
In order to attack a CTAP token over NFC you need to man-in-the-middle it.
In order to attack a CTAP token, I can tap it against an ordinary phone or a Proxmark or any PN532 device attached to a computer with some fairly straightforward software. There isn’t any authentication! It could be ECDH or SnakeOil-102400-super unbreakable for all an attacker cares: the attacker can just speak the protocol as specified.
edit: Okay, I found the pinToken mechanism in the spec. It is, to put it politely, not a PAKE. It has a trivial DoS attack by design allowing anyone nearby to destroy an authenticator. It looks vulnerable to an attack in which someone taps a malicious token against a phone or other reader, triggering the phone to try to authenticate, and thus captures the PIN, hashed but not even salted.
Oh, and I’ve personally never been prompted to set a PIN, and the UX looks miserable.
That's why you either use authenticators as a second factor only (i.e. you require a password entry first), or you require user verification (which is usually a PIN entry verified by the authenticator). Both solve this problem.
> There is no way to name a token to keep track of which one it is
Tokens support listing which credentials are stored on them, and most (not 100%, but most) tokens also support storing an arbitrary blob of data at least 1024 bytes in size. You can name your token if you want to name your token.
This does absolutely nothing to help me keep track of which physical gadget matches which token listed in the GitHub 2FA page without manually typing some kind of descriptor and hopefully getting it right.
Github lets me name my passkeys. There's a little pencil icon next to each one (on [1]), and as far as I remember it even prompted me for a name when I originally created it.
There does seem to be some way. I'm relatively sure I've seen keys pre-labeled with the name of my password manager in the past.
Some sites make bad assumptions, though, e.g. labeling every passkey I create as "iCloud Keychain" (because my user agent tells them I'm on macOS, and they assume that it must be that then).
> The concept of a passkey as desired by Apple, Google, and Microsoft is that every user magically authenticates using their OS, and has no ability to authenticate otherwise. [...] The reason the UX is confusing is because the OS vendors don't want the users using non-OS software or hardware
Completely untrue. Both iOS/macOS and Android offer an API for third party passkey implementations ("backends"). macOS also offers a client API for that that browsers ("frontends") can hook into. You can use Strongbox (a KeePass implementation) with Chrome, iCloud Keychain with Firefox, a Yubikey with Safari...
It's really as open an ecosystem as it gets at this point, and for software implementations, there isn't even attestation that could allow relying parties to block any specific implementation.
> The thing stopping us from getting to that ideal state is that the provider of the FIDO "platform" (the software that lets you choose a key to use) is the OS vendor instead of the browser vendor [...]
No, this "ideal state" is in fact the reality I've been experiencing for the past few months.
If this is so, could you explain why the dialog for a Google Play Services webauthn login today says "use passkey" (meaning "use google-account-hosted passkey") and "try another way" (meaning "present an options page to let me choose, after another click, a passkey that doesn't happen to be a google one")? How about the bit in the article where the Apple signin screen says "unlock with TouchID" and you have to decline to do that TWICE before you can use a hardware key?
Yes, it's technically possible to use hardware keys today. No, it's not ideal - specifically, what's broken is:
* the user experience where all three major platforms attempt to make it more difficult to use anything other than their platform.
* the ability to sync cloud-hosted passkeys between the major vendors AND self-hosted options
* the ability to decline to use the OS vendor platform once, instead of needing to decline it on EVERY SINGLE SITE, EVERY SINGLE TIME
> there isn't even attestation that could allow relying parties to block any specific implementation
This is, unfortunately, not true. FIDO2 credentials have support for an "AAGUID" and a signed attestation certificate that does, in fact, allow blocking particular implementations.
> How about the bit in the article where the Apple signin screen says "unlock with TouchID" and you have to decline to do that TWICE before you can use a hardware key?
> * the ability to decline to use the OS vendor platform once, instead of needing to decline it on EVERY SINGLE SITE, EVERY SINGLE TIME
This doesn't happen once you disable iCloud Keychain as an autofill option in the device settings in favor of a third-party integration. You could of course argue that it's anticompetitive of Apple to enable their integration by default, but I had to do this exactly once, not every time.
> This is, unfortunately, not true. FIDO2 credentials have support for an "AAGUID"
Yes, but neither Apple (at least for non-MDMed devices) nor Google (for synchronized credentials) provide attestation, so any relying party enforcing attestation implicitly excludes the two largest implementations, making it a non-starter for most use cases.
> the ability to sync cloud-hosted passkeys between the major vendors AND self-hosted options
This would be nice from a usability point of view, but it sounds like a nightmare to do securely. I'd be fine with a one-time import/export option, and that's being worked on.
>Yes, but neither Apple (at least for non-MDMed devices) nor Google (for synchronized credentials) provide attestation, so any relying party enforcing attestation implicitly excludes the two largest implementations, making it a non-starter for most use cases.
The discussion was about passkeys as a standard, so "well right now Google and Ape happen not to use this part of it" doesn't really change that. It could change tomorrow for all we know and there'd be nothing to be done about it.
By the people on HN who stay away from passkeys, this is one of the most commonly named reasons.
> It's really as open an ecosystem as it gets at this point
However, they fumbled the introduction by trying the “maximum vendor lock” approach first. Now they need to convince everyone otherwise, even if technically it’s open now.
I also wish they'd have started off like that from the beginning.
It might have taken them a bit longer to get the initial implementation out the door, but it would have avoided all of these discussions, which I'm certain are also impacting WebAuthN/passkey adoption across the web (assuming that the views on passkeys here are at least somewhat representative of technical decisionmakers).
But if the choice is between getting to the status quo via suboptimal intermediate steps or not having WebAuthN and passkeys at all, the former seems much preferable.
I disagree somewhat that that is a "fumble" so much as a symptom of what was necessary to get mainstream acceptance, what a lot of us on HN see as "maximum vendor lock" is also an attempt at building a "pit of success" for average, "boring" users. An "Uncle Charlie" with an iPhone, an iPad, and a Mac that trusts Apple and was already using iCloud Keychain as their primary password manager is going to have an easy time with passkeys and is going to have a harder time accidentally enrolling a passkey they don't understand or know how to use the next time or next device they login from. That's a reasonable "pit of success" for an average, "boring" user.
There's a lot of users that isn't great for. Especially there are statistically a lot of iOS users that use Windows desktop/laptops that Microsoft and Apple are trying to bridge but don't always have the best UX today. Same for Android and Windows users, there's statistically even more of those.
Also, as you can tell from HN comments every time Passkeys come up, HN is full of anecdotes of the craziest mixed device ecosystems people can build. We can be a loud set of users, and we certainly need the most convincing that our "power user" needs are met for all of our complexity requirements.
> anecdotes of the craziest mixed device ecosystems people can build
All it takes is for somebody to use both an iPad and an Android phone. iPads are relatively cheap (cheaper than many Windows laptops!); iPhones are quite expensive. That's a lot of users right there, and I think it must be at least as common as Windows + iOS users.
Right. That is not what I meant by "craziest mixed device ecosystems", and yes, I agree that Android + iPad is a common enough situation that needs good defaults that we haven't yet entirely solved for (but there are options today and hopefully it will get better). Windows "knows" it has to be a bridge device with whatever the user's phone ecosystem is, iPadOS today mostly assumes the user's phone "must be" an iPhone. From Apple's perspective that still makes sense as a useful "default" for what they consider to be their average user.
> No, this "ideal state" is in fact the reality I've been experiencing for the past few months.
I agree that technically, it seems possible to choose between hardware keys and OS passkey. But I also agree with the article that they try to push their own solution by hiding the alternatives, and that should not be allowed.
A) read the article, paying particular attention to the screenshots therein (ESPECIALLY particularly to the user experience on an Apple device), and
B) noted the part of my comment where I say that I should be able to set the choice of using hardware keys one time instead of needing to do so every time I create a new credential?
Today it's so hard to use a hardware key with Google Play Services that I (a software developer who actually works in this field) have had users tell me their phone didn't let them do it at all. In reality, the support was there, is was just so unusable they didn't even understand they had that option.
> installing a password manager providing passkeys would prompt to change the setting to use the password manager instead
iOS supports this today. If a password manager app describes that it implements passkey management, iOS asks what you want to be the default and the UI changes a bit to allow easier choices between iCloud and your password manager app.
It sounds like macOS is the place where Apple is lagging the most on API hooks that applications can use to trigger the UX.
It's also possible that Apple is just prioritizing that macOS users are mostly bought into the iCloud Keychain and their cloud infrastructure whereas iOS does have a large known mixture of iOS/Windows users that may bring their own keychains/password managers.
macOS also supports the APIs, but password manager developers don’t seem willing to implement them there.
I’ve used 1Password for a long time, but I’m probably going to drop it for Apple’s password manager because when users ask 1Password to add support, they are directed to use 1Password’s browser extension and universal autofill instead. Neither support passkeys in applications. I also find the browser extension buggy at times (especially with passkeys).
I'm aware of iOS' APIs because of Strongbox (iOS Keepass-compatible client), and someone also mentioned that macOS Strongbox does the same thing just fine. That is interesting that in this case it seems specifically a 1Password choice/disinterest.
If all your passkeys are synced to Apple, then it makes it really easy to use that new Apple device and really hard to use that PC/Android Phone/Meta VR headset/etc.
They are trying to make an import/export mechanism to prevent vendor lock in, but what if I want to still use my iPhone and my Meta VR headset. Import/export doesn’t mean sync :(
No, Apple directly benefits in that users only get the "magical" user experience when using Apple devices. There are two perverse incentives: one for Apple to lock their users into their platform, and one for Apple to implement a "better" experience unilaterally. Apple does both of these things.
Today, if I create a passkey on an Apple iPhone, and I pay Apple a monthly fee for iCloud, I can then walk over to an Apple Macbook I own and sign in to the same web site without another step.
But if I don't pay Apple a monthly fee, OR the phone isn't an iPhone, OR the laptop isn't a Macbook, then I don't get that user experience.
There is absolutely no technical reason that I shouldn't be able to get precisely the same level of security and precisely the same user flow without having to need all the devices to be Apple. But Apple chooses to restrict how it can happen.
Why do you say you have to pay a monthly fee for iCloud?
None of the technology you’re discussing here requires a paid account.
You may, separately, decide to sync more than the meager free quota of data on iCloud, but that’s an unrelated issue. You’re welcome to use iCloud just for keychain sync.
Looks good until Mallory sets up a phishing site that tricks users into installing a thing that registers itself as their “password manager” and mitms their entire life.
Not saying there aren’t other reasons the OS vendors are pushing back on supplying that hook, but that’s one that is at least vaguely pro-user.
The concept of a passkey as desired by Yubico was that every user buys a set of hardware keys, uses those instead of passwords, and has no ability to authenticate otherwise.
The concept of a passkey as desired by Apple, Google, and Microsoft is that every user magically authenticates using their OS, and has no ability to authenticate otherwise.
The reason the UX is confusing is because the OS vendors don't want the users using non-OS software or hardware - they want you to use a cloud-hosted passkey instead of using a Discoverable Credential on a Hardware Authenticator, and instead of using a password manager providing its own sync facility. This is shown in the screenshots in the article.
The ideal future state is:
* the provider for newly registered credentials would be a browser setting
* the setting would come configured to use the OS vendor out of the box
* installing a password manager providing passkeys would prompt to change the setting to use the password manager instead
* one of the options in this setting would be "prompt me every time". Approximately nobody would choose that option
* there would never be a prompt for what to use on authenticate() calls, only register(). Authenticate would use whichever valid credential you provided first, whether that's plugging in a token or scanning your thumb to unlock a TPM or whatever
In this world, 99% of people are using OS-vendor-provided cloud-synced passkeys, but technical users get what they want too and everybody has both a secure and an easy experience.
The thing stopping us from getting to that ideal state is that the provider of the FIDO "platform" (the software that lets you choose a key to use) is the OS vendor instead of the browser vendor, and they have a conflict of interest because the OS vendors are also cloud services vendors.