The passkey people won’t give you a straightforward answer because you won’t like the answer.
If the passkey is truly secure, you don’t get your key bak if you lose the passkey. If you make a copy of the passkey, the passkey purists will say it’s not “secure”.
If you lose your phone and delete your existing login cookies you don’t get access again. If email or sms is the recovery method, you might not be able to login on a new device or IP without your phone. But if email was the recovery method it’s just the same as sms 2FA which is reasonably secure and fail safe for the average person because there is a trusted third party in the loop…
> If the passkey is truly secure, you don’t get your key bak if you lose the passkey. If you make a copy of the passkey, the passkey purists will say it’s not “secure”.
That's an uncharitable interpretation. A more charitable way to say this is:
You can choose between secure/uncloneable and less secure but more flexible. Passkeys let you make the choice and don't dictate it for you. Choose whatever better suits your use case.
EDIT: I've written a short post to clarify a few misconceptions:
If it's the user, how do I as a user choose right now?
If it's the service implementing passkeys, why wouldn't they force a solution that's easier for them (less testing/less support/less maintenance, by forcing attestation to a specific list of providers), instead of letting users have an option?
Passkeys are an awesome solution to a difficult problem. But they are one bitflip away from eliminating user choice. Fix that problem, and I think folks here will jump on it in a hearbeat.
The user gets to choose. When enrolling an authenticator, you can choose what the authenticator is. I don't like Google's, so I use my phone and my Solo 2 as authenticators.
So here's how I implemented the recovery in my proof of concept. Your backup is performed using your backup private key, and the encrypted passkeys (private keys) are backed up to the server. If you lose your device, you obviously can't login and need your back up private key to recover. I implemented shamir secret sharing, it splits your passwords and you select from your contacts (other users who will agree to serve as your backup). So let's say you have 4/7, that means 4 people out of 7 people is all you need to recover your private key.
When you lose your device and reinstall the app. It asks you if you are recovering or a new user. If you select recovering your key. We will generate a new pub/private recovery key. Remember we are assuming you lost your phone. The app will then ask you to enter the phone number of the 4 people that will vouch for you. When you select those 4 people, a call is initiated to them where you must read off a code that the restoration server gave to you on your new device, they will then select that they are vouching for you. The idea is that these are your friends or people you trust. You have to convince them. Not just automated think. At that point their phone will send the pass key fragments to you (encrypted using your new pub key). When enough people give you the info you need. Your phone will decrypt with your recovery private key and then recover the backup private key.
It will then request the encrypted backup from the server. The server will provide it with the encrypted back at which point it will use the recovered private key to decrypt the backup and recover all pass keys.
Why? Security isn't an opinion, it's a science and art. It doesn't care about what you think of it.
Perfect security leaves no room for user friendliness. The most secure system allows no users to use it. Only by reducing security do you gain user friendliness. The most user friendly (as in, triviality of use) system requires no security.
The art comes in when trying to create more usability whilst giving up less security, of course.
Passkeys are more secure than passwords. Thus, it's only natural they are less user friendly. If you don't "like" that, then stick to passwords. There's nothing to condemn, however.
Availability is a major part of security (confidentiality-integrity-availability etc), so a process that has significant risks to availability can not be considered secure.
I like the part about passkeys where they avoid having a shared secret. Not so much the platform lock in and creeping remote attestation. Oh, don't worry, it's just in the spec, we're not going to do anything with it... yet. Seems like they're gunning for a world where if you're not using a blessed Microsoft/Google/Apple device you're locked out of it.
And I wish them luck. At least in my country (the same one I assume many of you also live in) our financial institutions haven't even implemented non-SMS MFA options yet. Literally the systems with the most impact on our daily lives (because they hold our money) haven't even stepped up to the security available in 2016 yet.
If a "reset passkey by email" option exists, they don't seem much more secure than a unique complex password + (non-SMS) 2FA.
So for most people on HN (who also probably won't be successfully phished) they offer only new problems, yet if implemented and used widely they're probably a net positive.
It's a bit like the Covid rules. I am more than capable of avoiding other humans without new laws, but "normal" people seemed to need a lot of coercion.
Personally I'll give it a few years and see how passkeys pan out before I switch (if I get the choice).
If the passkey is truly secure, you don’t get your key bak if you lose the passkey. If you make a copy of the passkey, the passkey purists will say it’s not “secure”.
If you lose your phone and delete your existing login cookies you don’t get access again. If email or sms is the recovery method, you might not be able to login on a new device or IP without your phone. But if email was the recovery method it’s just the same as sms 2FA which is reasonably secure and fail safe for the average person because there is a trusted third party in the loop…