Comment by sholladay | Hacker News Reader

Comment by sholladay | Hacker News Reader

Parent Full thread

I’m convinced that a lot of the passkey hate ultimately stems from the inconsistent and confusing flows that websites have implemented in the name of backwards compatibility with passwords. I have made some apps where passkeys are the only way to log in and it is such a lovely experience. It can be as simple as a single log in button by itself, with no intermediate pages or other UX. There doesn’t even have to be a form to fill out at all.

The problem of losing physical access to your passkeys is only really a problem if the site chooses to be strict. There can easily be a “Send a magic link” button where you type in your email. It’s the equivalent of “forgot password”. For most systems, it’s already accepted that your security is only as good as your email provider’s is. Passkeys make it straightforward to have an email-less model, but you always could have done the same thing with passwords. No one forced you to implement “forgot password”, it was simply a practical approach that was worth the security tradeoff.

People seem to assume that we should leave that functionality behind in the transition to passkeys but I’m not so sure. It certainly seems more practical than trying to get users to maintain physical backup keys.

The concern about exporting passkeys is valid but you can share via AirDrop. Doesn’t that work on Android now?

Try to give passkeys a chance. I really think the growing pains are worth it.

Nah, it's the transmission of the keys to Apple or Microsoft. We flatly rejected key escrow during the Clinton Administration, and I continue to reject it. And no, I absolutely do not trust their implementation of E2EE to mean there are no backdoors.

Are you aware that none of that is required when signing up for a site that supports passkeys?

I think there is some confusion here caused by sloppy use of terminology among FAANG and the standards groups. You’re right that, strictly speaking, Apple defined “passkeys” as synced credentials. And you’re also right to point out that, as a result, in order to consider them secure, you must trust Apple’s key storage and E2EE iCloud syncing, or the equivalent from other vendors. I wouldn’t blame you for being skeptical about synced credentials. The convenience may not be worth it for you.

However, crucially, synced credentials are just one type of FIDO2 credential. The other is a hardware-bound key from a “roaming” authenticator (aka a “security key”). These are never transmitted, never synced, and you can buy the security key hardware that generates and stores them from many different vendors, all of which are designed to be interoperable.

In other words, all passkeys are FIDO2, but not all FIDO2 are passkeys. Yet, when a website says it supports passkeys, it probably means it supports all FIDO2. And that’s because WebAuthn, the browser standard used to implement passkey registration and authentication on the web, supports all FIDO2 credentials, not just passkeys.

With WebAuthn (and most other systems), by default both platform authenticators (which would typically be synced, like you’re talking about, but not necessarily) and roaming authenticates (which would be typically be a USB security key, not synced) are allowed. I’ve occasionally stumbled upon sites that don’t allow platform authenticators, but I’ve never come across one that doesn’t allow roaming authenticators. It sounds like you want is the latter.

Apple could have avoided this mess by simply deciding that “passkeys” are the new name for “FIDO2 credentials” and then we could have synced passkeys and non-synced passkeys. But they apparently thought that was too confusing.

Ok, thanks for the explanation covering everything except the topic of my comment. And yes, I was aware. The point is, nobody (except those with a condescending PhD tone of voice) is aware of the loophole inherent in synchronizing passkeys.

Reply on news.ycombinator.com