Things I Learnt About Passkeys When Building Passkeybot

This is like those "contact your system admin" error messages. I am the system admin!

So then the follow-up suggestion is to use credential exchange. That's not actually a solution, but by the time you explain that to the passkey proponents they've usually stopped listening.

the capability is there, but it would he massively inconvenient, since it requires a lot of lockdown

might be the next generation of anti-cheats though

But the existence of attestation means Apple could at any time in the future make attestation on by default and suddenly our devices control our secrets more than we do.

> personally think the ability to export+import passkeys is a good thing from a backup point of view

It's not a "good thing," it's absolutely critical. If I can't back up my credentials in a location that I trust, then it's not an acceptable login method. What happens if my PC goes down and I couldn't export my data? I just can't log in anywhere? KeePassXC lets me do that, but the spec authors think it's appropriate to ban me for using it because it lets me manage my own data. That's bonkers.

1) that they're enforcing these specs for technical reasons, not because they want vendor lock-in

2) a result of these decisions in the long term is vendor lock-in

No, that is absolutely not the point. The points of using pub/priv keys for asymmetric auth instead of passwords (symmetric, manually generated auth) are:

- Server-side (ie, central point) hacks no longer matter an iota from a user auth pov. No more having to worry about reuse anywhere else, about going around changing passwords, nada, because the server simply doesn't have anything that can be used for auth anymore at all. No more concerns about whether they're storing it with the right hash functions or whatever, they could publish all the public keys in plain text and it'd be irrelevant. This fantastically changes the economics of attacks, since now instead of hacking one place and getting thousands/millions/hundreds of millions of credentials you'd have to hack every single separate client.

- As a practical matter, the process means eliminating the whole ancient hodgepodge of password requirements (often outright anti-security) and bad practices and manual generation work. Everything gets standardized on something that will always be random, unique, and secure.

And that should be it. That's the point and the value, always was. The only goal should be to put a nice UX and universal standard around. But of course, modern enshittified tech being enshittified, they had to shove in a bunch of stupid fucking bullshit garbage like what you're talking about.

I think we're verrry slowly inching toward shedding all the security nerd self-indulgences and getting to what I think is the eventual endgame which PassKeys are just keys and ultimately a fairly user friendly way of getting people to use a password manager without it feeling like one. All the other features seem like noise.

As stated by the spec authors on KeePassXC's bug tracker, open source software may be modified by the user, so cannot be trusted. The passkey proposal is for all of your keys to be managed by proprietary software validated by your phone or your computer's TPM module. That means one of three big, US-based tech companies will control all of the world's login data. Those 3 companies are all currently involved in the largest fascist-taint-tongue-polishing in US history, and we want to hand them control over the world's logins. That's a much, much bigger risk than some users doing something stupid.

Apple wants you to use iCloud passkeys, Microsoft wants you to use Microsoft Account passkeys, Google wants you to use Google passkeys. Even if you have a dedicated USB device plugged in, browsers keep defaulting to the cloud accounts.

Bitwarden's approach is to simply hijack the passkey request before the browser can respond and throw itself front and center. It's a terrible hack but it works on every browser at the very least.

If these companies cared about their users more than they cared about throwing up walled gardens, they wouldn't put a USB key behind "Choose another method" -> "Dedicated device" -> "Security key" -> "Confirm" while offering one-click login with their cloud account. And they would offer a proper API for third party applications to integrate into the native passkey storage.

In practice we don't actually want the best security though. We frequently make concessions. I mean with my bank I don't want "the best" security. If I lose my credentials I don't want to go broke. If my credentials get hacked (especially if hacked by no fault of my own!) I want that money recovered. These things would not be possible with "the best" security.

In fact, in a different interpretation I would call those paths less secure. Ability to recover is a security feature just as much as it's not.

Both security and privacy do not have unique all encompassing solutions. They are dependent upon the threat model.

Importantly when designing things you have to understand modes of failure. When you design a bridge you design it to fail in certain ways because when/if it fails you want it to do so in the safest possible way. Why does this pattern of thinking not also apply here? It seems just as critical here! In physical security you also have to design things for both fail open and fail closed. You don't want you always fail close, doing so gets people killed! So why is the thinking different in software?

I've never seen a legitimate use case where I need to prove my identity to use a website.

The messed up thing is that the simplest backup option is a magic login link which is obviously less secure. Also you cannot sink a passkey between platforms unless you use a third party Authenticator so you have to have a backup method of some sort even if not for recovery reasons.