> 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!
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 an ideal world, I'd prefer that to.
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.
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.
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).
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.
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.
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.
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?
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.
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.
> 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.
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).
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.
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.
> * 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.
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.
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.
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.
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.
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.
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.
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).
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.
https://developers.yubico.com/WebAuthn/WebAuthn_Developer_Gu...
https://www.reddit.com/r/webauthn/comments/197ggm7/comment/k...
The only one that I witnessed, is the optional passkey for restoring your Whatsapp account
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.
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 :(
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.
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.
Presumably, yes.
> So they should get onboard with what is best for the user.
What happens when there’s a conflict? They usually go with the option that screws the smaller niche user base.
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.