The original U2F tokens didn't suffer from this problem that much. It contained one secret, it relied on the website to store and return an opaque website-and-account-specific blob, which was decrypted by the token and used to sign the login request. It would be reasonably easy to expand this in a way where the server also stores a backup credential for use by your second/third/whatever hardware token, encrypted with an asymmetric key during the enrollment of the primary token.

But this went out of the window when some genius decided that usernames were too complicated, so Passkeys had to be discoverable, which means they have to be fully stored token-side. Which of course has the nice side benefit of essentially killing hardware tokens and forcing people into using their Android/iOS/Windows device for it.

Passkey comprises of public key that the website you created it on holds, and the private key you store on your pw manager or in the TPM/secure element. As long as you can copy the private key to the new device, you don't need to recreate the whole passkey. In your case, you would just need access to a backup of the Keepass database in case you lose the device.

The biggest point of confusion in my opinion comes from Windows especially having lacked a way (and kind of still does) to save the private key of a passkey to your password manager, defaulting to saving it to Windows Hello, which saves the private key to your PC's TPM. In this scenario you can no longer easily copy the private key to other devices, and if you lose that Windows PC, you also lose the private key and the whole passkey as a result.

1) Install a keepass client and use it for passkeys.

2) See #1

3) See #1

KeepassXC supports passkeys. They suggest a couple mobile apps that also do.

[dead]

> Let's assume that they were all Passkeys.

Lets assume I put all the effort to explain.

I will give you a better example.

- Lets say you have a google account with pixel phone

- You are using it and added 1000 passkeys

- All are synced to your Google account

- Destroy and Get a new phone. Login to your google account with recovery code.

- All your passkeys are in your phone again.

There are plans in fidoalliance.org to make it portable. Pretty sure you are still not going to move to it.

Apple's keychain or google password manager - can hold 2000 passkeys easily.

> The reason passkeys have their own name and definition is because they are meant to be a phishing-resistant primary factor that competes with the UX of passwords. And a great usability trait of passwords is that they’re convenient to use across all your devices. With a technology involving public/private keypairs, the only possible way to compete with that UX is to sync the private key across the user’s devices.

Another way would be auto-enrolling passkeys from other devices you own through a standard API. Enroll your trusted Apple device in your Google Account's settings, or your Bitwarden/KeePass, and vice-versa. When your iPhone creates a passkey at a site, iCloud notifies Google, which issues a new passkey and sends the public key to iCloud, which auto-enrolls it at the site alongside the iCloud passkey. BitWarden gets the same treatment. When you open your KeePass vault it checks Google and iCloud and picks up any pending offers for passkey enrollment and completes them.

Simple, secure, opt-in, and users control their devices and passkey vaults with minimal hassle. If a device is lost, the other services can help you automatically delete the compromised passkeys and set up your new replacement device.

Matter does something very similar with cross-compatibility between Apple and Google (and the rest of the ecosystem) when new devices get enrolled with the user's choice of PAA; the only thing missing is roughly cross-PAA enrollment but that would be just one additional trivial trust relationship in both ecosystems.

> the only possible way to compete with that UX is to sync the private key across the user’s devices

This is my issue with passkeys. Either we lessen security to improve UX (syncing across devices implies extracting private keys from secure enclaves, at which point it’s no different to password syncing), or we have a proliferation of different keys per website across devices (assuming the website supports multiple passkeys).

Perhaps this trade off is not resolvable in a way that happily satisfies both the security constraint and the UX requirement.

> Right; but THAT idea is consumer hostile by design.

No argument from me there, just stating what the design actually calls for.

It was never meant to be consumer friendly in the first place, it's an enterprise standard. It was just shoehorned onto consumers with the synced credential compromise to make it easier, instead of coming up with something better, and then just calling it a "Passkey" which now has dual meaning.

But the real solve is difficult. If a system requires a consumer user to manage, remember, or safely store something extra, it will fail.

Passkeys is basically a brand name for "discoverable credentials" (a Webauthn term). They do a little more than that technically, but in practice their purpose is what you said. Replace passwords. Or more accurately usernames and password pairs. This is in contrast from 2FA, but even before Apple started marketing Passkeys the FIDO standard supported the concept of Passwordless authentication, alongside 2FA.

Passkeys came together with multi-device syncing when Apple introduced them and IIRC it was pushed as their killer feature by Apple back then, but passkeys can also be completely device-bound. The marketing around this was all quite confusing, but it's a bit too late to fix now.

What we got, as far as the average consumer should be concerned, is that "passkey" is any authentication mechanism (not the actual credential) that can replace a password. And it's still confusing.

> Passkeys are primarily meant to replace passwords

Unfortunately, the designers of passkeys decided they should replace passwords and usernames and second factors.

Also they decided they should be cloud-synchronised, so the something-you-have second factor doesn't impose the burdensome requirement for you to have something, which was apparently a big usability problem.

> A particular service can choose to enforce those class of passkeys

And that's exactly why the technology should be rejected while we can. It's no business of a particular service how I use my devices.

Stronger than "don't care about" (at least if I and some friends I've discussed this with count as normal people): this is actively what I don't want! I want control over my authentication and I don't want it bound to device, browser, OS, etc.

I mean, no one ever said it was a good design.

But the original FIDO2 standard wasn't made with consumers in mind in the first place, it was driven by enterprises that wanted high-assurance security. It works in that environment because, well, a big IT department controls it, can support the employees, and you can mandate and control its use.

It was just sort of haphazardly shoehorned onto general users/consumers, prematurely IMO, via synced credentials as a compromise instead of coming up with something better.

Easy: it's the token on your physical keyring, right next to your house key and car key.

It's not a nightmare, in fact different sessions of the same user could be used to grant different capability levels across sessions depending on the trust level.

That's self sovereign identity. But you still need someones that can issue those verifiable credentials, and we (as a global society) can't decide who that should be in the web of trust? Our banks? Governments? Schools? Doctors at time of birth?

Arguably, that's the only way forward. SSI is also nice because you get to fully control what you share and don't share (e.g., age verification, you get to only share "I am over 21" and no other information).

Passkeys were (are?) supposed to be just a password replacement though. That services are using them to replace a username AND a password AND 2FA is a problem that's turning the device into your identity, instead of keeping the identity as three parts (What you know, what you have, who you are (biometrics)). Now we've just turned the "something you have" into the entire identity stack.

How do we verify that you are you? It can't be linked to fingerprints, iris scans, or DNA, as those are trivially leaked, impossible to change, and a privacy nightmare.

Until we find a way to securely implant a Yubikey in people's brains, it isn't going to happen.

By still having the password the user can still be attacked via phishing

Replace the word passkey with password in your comment. What’s the benefit of passkeys again?

If you’re not storing the actual private key in the Secure Enclave but only the “access to it” what’s changed from how Apple’s keychain already manages password syncing to iCloud?

The only benefit (and it’s still a decent one) is that some random website breach can’t disclose your private key.