I thought "Passkeys are a trap" was going to be about this usability nightmare. Some sites, once connected via passkey, make it all but impossible to connect in another way. Some support multiple passkeys. Some do not. Some support passkey or something else. Some do not.

The idea and protocol are pretty solid, though we're back to a "biometrics as password" problem in many device flows, but every time I'm urged by a site to convert to a passkey, I wonder "is this site the sort that would screw this up?"

So far, it's about 30% of sites screwing it up...

Supporting multiple passkeys should be a minimum requirement for every Passkey implementation. It's generally worth naming and shaming the websites that don't implement that correctly. People want backup passkeys. People want both iOS keys and Windows keys for the most convenience.

My general advice for non-technical users that seems to work pretty well is "sign up for new sites with passkeys on your phone" because most non-technical people trust the password manager ecosystem on their phone, have some amount of multi-device sync already established, and the QR code started Bluetooth LE flow on desktop/Windows PCs for sharing passkeys works easiest with phone passkeys.

(I run a tiny site that is Passkey Only for login and it's been interesting providing technical support for it. One of the biggest recurring issues at this point is nothing in the Passkey flows themselves but the fact that the Facebook in app browser does not support Passkeys for a number of presumably security reasons, plus Meta being jerks, and having to remind new users to "Open in External Browser" before signing up/logging in when posting links to the site in Facebook.)

> The idea and protocol are pretty solid, though we're back to a "biometrics as password" problem in many device flows

It's still just biometrics as "device PIN". The crucial difference remains that the biometric data never leaves your device. To support Passkeys the remote website only ever sees your Passkeys' public keys, they never see biometric data, they never have a chance to store biometric data in a database to violate PII/HIPPAA/etc standards when it inevitably leaks to "hackers" (or gets sold to the highest bidder).

This is the issue.

I can’t adopt Passkeys if I’m not certain they’re going to work as well as my password manager and Authenticator app, which is to say 100% of the time.

When sites ask to set up passkeys, it’s usually native passkeys (especially on iOS). And figuring out how to get the flow to set up a LastPass key by default seems unusually difficult.

I also use a MacBook, windows desktop, an iPhone and iPad. I use Firefox, edge, brave across these devices.

When I say “passkeys are a trap” they are a usability trap where no one can attest with certainty that I won’t wake up in a painful situation because I decided to adopt passkeys.

This is why I don’t like passkeys. I’m surprised the “use site from multiple devices” use case isn’t more common.

Am I nuts for accessing a site from both my mobile phone as well as from the multiple computers I use?

This also gets super messy when combined with multi-site auth services like id.me where I need to use the same login to access very diverse sites and services from multiple computers (eg, irs.gov, treasurydirect.gov, disburser.treasury.gov).

My takeway from “Passkeys are a trap” is that there are like four different approaches to something that everyone just calls “passkeys”, and they are not the same. For example, some are portable and some are not.

> Some sites, once connected via passkey, make it all but impossible to connect in another way.

That's the issue I had with Okta a few years back. I used a password then later added a passkey through Bitwarden on my work laptop. Bitwarden hadn't yet implemented passkeys for mobile.

I went to authenticate through Okta on my work phone. It prompted me for the passkey. Since mobile passkeys didn't exist, I got stonewalled. I had to make a blood sacrifice just to get Okta to allow password access again.

The trap is the ratchet towards attested hardware and closed-source-only implementations.