I personally am wary over passkey. An Android update to my S21 earlier this year dropped support for hardware keys. Now whenever I try to sign into a site that expects my hardware key the Google passkey dialog pops up and I have no way to use my hardware key to sign in. I wouldn't mind passkeys if Android continues to support the hardware keys alongside passkey but to replace the former with the latter is a step too far for me. I do wonder what the motivation behind passkey is if they're willing to drop support for hardware keys without any notification and push passkey instead.
Passkeys have attestation as a specified feature and nothing about interoperability, so the motivation is exclusion of certain classes of devices from services.
I assume you're talking about attestation here, not authentication? My question is, as always:
> At least none of the existing implementations do.
So why isn't that in the spec?
Unless something has changed in the past month or so, the only reason why attestation for roaming keys is less of an issue is because Apple has voluntarily completely of its own volition decided to zero out information in its implementation. That's turned out not to be enough; it's trivial to find accounts online of people complaining that they've tried to register passkeys from alternate providers and have found out that websites are checking browser agents or using other measures to restrict which keys can be registered.
But ignoring that and only focusing on actual attestation using the mechanisms that FIDO has built into WebAuthn, why is an Open standard relying on Apple's goodwill for such an important decision? Why do we have a standard that specifies how to lock down devices through hardware attestation and that relies on providers optionally choosing to do the right thing and ignore that mechanism, but that thinks it would be overreaching for the Alliance to mandate ecosystem transfer or to block discrimination against providers/authenticators?
> ...it's trivial to find accounts online of people complaining that they've tried to register passkeys from alternate providers and have found out that websites are checking browser agents or using other measures to restrict which keys can be registered.
I knew this was going to happen but I thought they'd wait until there was more broad adoption before the screws started turning.
In their survey question they mentioned "fido2 and passkeys", so it's not clear how many are pro passkeys and how many had yubikeys in their mind. And the question isn't asked directly. They ask if passwords are here to stay and the answer options aren't about what the surveyed person would like to see in the future but more about what will happen in the future. e.g. "they [passkeys and fido2] will replace passwords" instead of "i want them [passkeys and fido2] to replace passwords"
> Are they conflating fido2 hardware tokens with “google owns your credentials, and you can’t back them up” passkeys?
Passkeys are an open standard, not a Google SSO service. You can use it with Apple devices (where passkeys shipped well before they did on Google devices), 1Password, etc. without having a Google account at all.
The concern around backups is partially true (backups are possible, exchange between implementations is in progress) and I think that’s where the confusion is coming from: the whole point of passkeys is that your private key can’t easily be stolen and the first implementations did that only within specific services with known characteristics - for example, Apple’s iCloud Keychain robustly backs up the keys (even against complete loss of all devices) but only in that service, which is understandable given their audience and the exposure. All of the major vendors have committed to interoperable private key exchange as things mature and we’re already seeing that with e.g. 1Password and iCloud Keychain allowing you to share keys with other people.
> Passkeys are an open standard, not a Google SSO service
This ignores the practical reality of every single implementation of Passkeys today. The fact is, call them Open all you want, the implementations are almost entirely proprietary. The official dev site says they don't work on Linux (https://passkeys.dev/device-support/) and in fact doesn't even list Linux as a target (only Ubuntu), and doesn't even list plans to support providers on Linux. Numerous people have said that exchange between implementations is in progress, but there's basically zero information about it (the spec process and design of exchange seems to be happening behind closed doors as far as I can tell, or at the very least I don't know where to search to find the meeting notes), and there's no timeline at all about when it will be supported, and in the meantime no major passkey provider from any ecosystem supports transfer.
But that hasn't stopped any of the major providers from launching passkeys to the general public and advocating that people start using them today.
So forgive me for being doubtful that the industry actually cares, because they clearly didn't care enough about this stuff for it to be a blocker in front of asking people today to commit to ecosystems that have zero transfer systems in place if anyone needs them. Vendor lock-in is not a theoretical future concern; every passkey system being advertised to users today is currently vendor lock-in. We are past the point of lock-in being a future concern, today passkeys as they are presented to most users are almost entirely walled gardens and the only silver lining is that we have vague promises that the existing problems that make passkeys user-hostile right now might be fixed in the future.
But that's apparently OK because ordinary users who can't be taught not to reuse passwords will just remember to make multiple keys across ecosystems for every website, and them needing to do that is apparently fine and nobody should complain about it or point out that it's not a reasonable thing to ask nontechnical users who can't wrap their heads around 2FA codes to do. /s
And I don't know, I don't think that people get to use "when the ecosystem matures" when Apple is telling its users to start using the ecosystem today. The ecosystem is mature, the industry has decided the ecosystem is mature enough to launch. The features that are still not implemented are features that the industry has decided were not essential parts of the standard. The industry and FIDO Alliance did not care enough to implement those features before launching passkeys and advertising them to regular users.
----
So passkeys are an industry standard, but I am increasingly doubtful that they are an Open standard in any of the ways that actually matter. Just because the docs are public, that doesn't change the fact that the major implementations are effectively closed silos today. I don't know if I'm being greedy or if I'm spoiled by web standards processes, but I would expect an Open standard to have Open reference implementations that work on every single OS. I think it's weird to have a bunch of proprietary implementations and a spec for providers that is theoretically possible to implement on Linux but matters so little to the FIDO Alliance that the official dev site doesn't even list Linux as a target. Imagine if Matrix didn't have an Open client or server reference implementation. Imagine if that entire process was happening behind closed doors and the only way to get news about what the Matrix devs were working on was to ask on Reddit or Mastodon or Twitter.
Would we call that an Open process?
----
> All of the major vendors have committed to interoperable private key exchange as things mature and we’re already seeing that with e.g. 1Password and iCloud Keychain allowing you to share keys with other people.
Genuinely, not as a joke or a gotcha but as a real request, I would love to see actual documentation about this, because maybe I'm bad at looking but I've gone through the official passkey sites and I search online about this regularly and I can't find official confirmation of this from most of the major vendors. Arguably Apple seems to have committed? But it's tricky to actually determine that because I'm never sure if they're talking about cross-device access or if they're actually talking about transfer.
I would love to see a section on the actual passkey.dev website committing to key exchange, that would make my day. I would love to see confirmation not on Twitter or a blog that companies are committed to this as more than a "nice to have whenever we get to it, but in the meantime just start using them, what's the problem." I would love to be wrong about this, please show me an official document from the FIDO Alliance itself saying that key exchange is going to be part of the standard and is going to be a required part of certification and giving even a semblance of a timeline about when it's going to exist.
1Password constantly gets brought up as evidence that interoperability and lock-in isn't going to be a problem, but 1Password does not support transfer between ecosystems and while they have said on Reddit that they are interested in avoiding vendor lock-in, I can't find official confirmation of that on the site and there is no timeline or details about how that's going to work. And again "it isn't going to be a problem" doesn't cut it anymore, people are recommending that users start adopting passkeys. It is a problem now. When a system gets launched and recommended to regular users and that system is missing critical infrastructure, that's not a future problem anymore; now it's a current problem.
I think the negative sentiment towards passkeys I've seen on HN is about how bad the experience has been setting them up. If you are using a non-standard browser there were plenty of parts of the process that fell over.
> Are they conflating fido2 hardware tokens with “google owns your credentials, and you can’t back them up” passkeys?
This article isn't even negative! It's pointing out that passkeys could make most security keys obsolete because they lack the storage to store resident passkeys for lots of sites.
It even provides recommendations to work around this problem.
Most if not all services which I use that supports Passkeys allows you to enroll more than one per account. I have my phone (Android), my laptop (Windows Hello) andnmy primary and backup Yubikeys enrolled. I'm not restricted to a specific platform.
That this is not a required part of the spec and that it's possible for a website to go through certification and get an official endorsement of support without supporting multiple keys per-account is a complete failure of the FIDO Alliance.
One of the big issues with how passkeys are being developed is the painful naivety of the FIDO Alliance about actually standardizing good behavior.
Every response is, "but why would providers do X bad thing?" If we're expecting every provider to allow multiple keys, then require it in the spec. Otherwise, if it's important that the spec not mandate that, then don't tell me that every provider is going to allow multiple keys, because apparently there's use-case for only allowing a single key and we're expecting the spec to need to accommodate that behavior.
----
> I have my phone (Android), my laptop (Windows Hello) andnmy primary and backup Yubikeys enrolled. I'm not restricted to a specific platform.
That people are seriously suggesting this as a solution to cross-ecosystem recovery and backup makes me skeptical of the potential of passkeys to ever be simpler or more straightforward than passwords are. Normal users can't be taught not to reuse passwords, they can't be taught to do 2FA, and you think they're going to proactively enroll multiple keys in every website they sign up to?
That's not going to happen; what will happen is they're going to lose their Android phone and they won't be able to do cross-device authentication without it, and they won't have proactively done cross-device authentication on their Windows machine, and the only way to get access to those keys will be to buy another Android phone. "Register multiple devices ahead of time" is only a solution if you expect passkey usage to be restricted to niche technical groups.
Which platforms allows you to enroll your yubikey as as a passkey? I know Google for example does not support hardware keys within their Passkeys system and that's a major gap IMHO.
Uh.. I enrolled my Yubikeys as Passkeys without any problems with Google.. just be sure Windows Hello doesn't get in the way, and be sure to select your USB device when enrolling.
Sure, but the man on the Clapham omnibus is going to use Apple's, or whatever's, that's what I don't like - it seems set up to serve incumbents rather than to stand on technical merit.
There's precedent for only supporting certain walled gardens, too: Google MFA sign-in supports Yubikeys et al. only if used in Chrome; in Firefox for example you get the prompt and everything, it just stubbornly refuses to accept it on touch.
> Google MFA sign-in supports Yubikeys et al. only if used in Chrome; in Firefox for example you get the prompt and everything, it just stubbornly refuses to accept it on touch.
Ok you made me look because I was sure I had been doing this every morning; Myth busted - Logged in to Google using a Yubikey via Firefox (Windows 11) no problems at all.
Bitwarden, where are you with a good Passkeys solution? I know I don't want Google nor Apple in control of my private keys (even encrypted) I'd rather see a solution from you.
But! I would rather you take your time and do it well, than rush it.
Just looking forward to what you'll bring to the table with Passkeys.
My understanding is that it's coming at the end of October. So it should be out soon.
I've also been waiting with bated breath; I simply won't adopt passkeys until I can use a cross platform tool that doesn't try to lock me into a single vendor's hardware or software. But once that's available, I'd be very happy to switch certain accounts to passkeys. It doesn't matter all that much to me since I use unique, long passphrases generated by bitwarden for every account + OTP when I can, but I would slightly prefer a passkey to a password since it's one less thing an auth provider can screw up.
1. You prove you have control of a key without telling the service the content of the key (like SSH keys, and any other PK setup) so: you cannot lose your password. The private part probably never leaves your device (probably - if you use Apple or Google's implementation there's magic/low security sync, you might also manually backup the private keys to a file)
2. A new keypair is generated per service. Don't reuse your password is baked in the spec, and by using individual keypairs the service can't profile you by the public key (privacy).
3. And possibly the most important. WebAuthn (of which Passkey is a popular marketing term) includes the asking identity during the registration/signup and login/proof stages, it doesn't rely on the user inspecting the url/webpage look/auth domain. Ie. You cannot be phished by examp1e.com when connecting to example.com (much like SSH's TOFU, but sorely missing from most web interactions).
TIL about 3)! That's fantastic to hear. Password managers sort of do this already, though.
So if you're a competent password manager user, only 1) matters. Passkeys really do seem like a bigger deal to your average user, since 2) and 3) implicitly incorporate password best practices.
This seems to be the description of SSH keys capabilities except the user does not control them. Why did they not just use SSH keys? They are much more familiar, and all major bugs are already squashed for years.
The general idea behind passkeys (and WebAuthn in general) is fantastic. They're phishing resistant (not totally phishing-proof, but way better than existing auth methods). They eliminate entire categories of phishing attacks around site identity. The UX flow provides users who would not be making secure passwords with strong-by-default security, making password reuse almost impossible. Even the cross-device authentication stuff, while not sufficient on its own for things like backup is still an improvement over copying and pasting keys.
Being able to authenticate a device and log in without ever transferring your authentication credentials to that device is cool. That enables some security setups that would otherwise be very difficult to build.
Some of the benefits are oversold (the privacy benefits seem overblown, there is nothing about passkeys that guarantees that your accounts won't still require email addresses, and there's nothing about passwords that forces sites to ask for email addresses, so nothing on that front is likely to change) -- but in general, the core idea is wonderful and passkeys would be a massive improvement over passwords if they were implemented well.
The problem is the implementation and the development process for the spec.
Passkeys are intended to protect the tech-incompetent masses against trivial attacks. They provide zero or negative value to the HN crowd who's already using a password manager and 2FA.
They certainly didn’t ask the HN crowd. I wonder who they surveyed.
Are they conflating fido2 hardware tokens with “google owns your credentials, and you can’t back them up” passkeys?