You can create backup keys by creating more passkeys.

That's not a backup, that's just another secret. If I can't record the secret onto paper that I can put in a safe deposit box at a bank (or several), then it ain't backed up.

It’s an equivalent key. It unlocks the same door. It doesn’t matter if it’s the same bits, because the only thing we care about is whether it unlocks the door.

Two different combinations for the same lock serve as backups for each other for practical purposes.

They could even be entirely different methods of access, like a Yubikey or backup codes. What matters is that you have independent ways to get in.

I understand the semantic difference but wouldn't you be able to say add a "backup" Yubikey and lock it in a safe?

Quite convenient when you need to create a new account...

No. How do you use it if it's in a safe? The only way this works is if you use the yubikey to log into google or some other auth provider and then use that auth provider for everything. But you are even worse off then as that auth provider now is a single point of failure... get that account revoked for any reason and you've lost access everywhere.

Why do that, though?

Figure out which doors you need to unlock and make sure you have at least two independent ways to get through each door. Some doors support Yubikey, so that counts as one, for those doors.

But why do THAT when what were asking for is control over our own data, our own secrets? Because it's imagined to be "less secure"?

Actually backing up keys, as in duplicating them and physically securing them, makes it simple, clear, and understandable to all involved what recovery looks like. TOTP is a great example in a similar space; my nontechnical spouse doesn't need to know "how TOTP works" to know that in case of my incapacitation she only has to read a packet of paper and follow instructions in order to perfectly recover all my accounts with zero chance of some 3rd party provider (e.g. Passkey stores like 1password/Google) having a political/technical glitch that'd get in the way of that.

Passkeys are like passwords with landlords added in. Just like with landlords for services provided, Passkeys seem very convenient for day-to-day but nightmarish in the margins and on the 5+ year scale.

My doors don’t change every other week. My set of passkeys does.

If you need (and therefore have) access to your safe every other week, chances are it’s not actually very secure.

I don't think that's really a workable solution.

> mainstream

The qualifier “mainstream” is quite silly here. Bitwarden and KeePassXC work great, can be backed up, and meet your needs. Why must “mainstream” providers support power user features?

In-practice, 1Password, iCloud Keychain, etc are backed up because they work across devices and those systems already have recovery mechanisms in place if you lose your devices. They’re synchronized credentials available everywhere.

The only way to make a problem is to “store a passkey locally”. Then you’re out of luck. If you just use Bitwarden or KeePassXC, this is a non-issue.

> It could be so simple, just look at SSH keys, which I think largely use the same principle.

Passkeys are technically complex in implementation because they’re trying to be better than passwords for the lowest common denominator of users. If you spend time looking at how they work and interact with sites, the solution is relatively simple and easily understood. Maybe they’re just unfamiliar to you? I personally have never explained to a layperson how SSH keys work without first explaining PKI, which is a pretty big ask for my mom.

I’m already using a password manager. I struggle to see the security benefit to storing passkeys in them.

On the other hand I like the security benefit of hardware passkeys. But these are unusable because 1) most sites that support passkeys don’t support registration of more than one passkey, and it’s hard to determine if they do or not, and 2) the security benefit is defeated if sites allow recovery without a registered passkey, which most do, and again it’s hard to figure out if they do or not.

So what’s the point?

As a counter-point, my SSH keys are bound to my laptop's secure enclave and it's not possible for me to back them up.

I have recovery mechanisms for regaining access if I lose all my keys, but (while I'll admit that the tooling for managing public keys in the general case is lacking) you're not supposed to (need to) copy private keys between devices.

That was basically what I was going to say too. The most secure keys are the ones that can't be transferred. If I want protection against the loss of a hardware security key like a Yubikey, I have to get a second one and register that one as a secondary key to log in.

Technically you can generate a GPG key and load that onto multiple Yubikeys, but that's not as secure as letting the Yubikey itself generate the key. Plus if you only use one GPG key and one of the Yubikeys is lost (but not destroyed) then you have to rewrite all the remaining Yubikeys with a new GPG key since you can't selectively revoke them.

if you can get a backup, someone can get scammed into providing that to an attacker, taking away any security benefit.

To be fair, the webauthn spec expressly forbids facilitating the extraction of credentials from the authenticator (though arguably even syncing between devices violates the spec).

If the vast majority of implementers (by users) are not compliant with a spec, that arguably says something about the spec as well.