[afiori]

As any kind of key you need to be able to replace them after you lose them (think of a flood or a house fire) so either:

1. You accept a non-trivial risk to be locked out forever of what you used those keys for 2. You still have a password login to revoke/create keys 3. You invest in enough redundacy to never lose all of your keys

IMHO only 2. is viable and then keys are just a different implementation of a password manager.

[lxgr]

My keychain has two physical keys, and these change only every time I move.

Of passkeys, I have quite a bit more, with new ones added at least every few weeks. That makes them much harder to physically or even logically replicate one by one.

[afiori]

> My keychain has two physical keys, and these change only every time I move.

How often they change is irrelevant, the point is how you would recover them.

> Of passkeys, I have quite a bit more, with new ones added at least every few weeks. That makes them much harder to physically or even logically replicate one by one.

But what is your plan if you lose them? either you plan to never lose them (3.), you have a way to replace them (2.) or you accept the risk to get locked out (1.)

[lxgr]

> How often they change is irrelevant, the point is how you would recover them.

How is it irrelevant if I can only use my recovery authenticator for the services I’ve enrolled it in, yet enrolling multiple physically separated authenticators is a huge pain practically?

It’s like changing the locks on various doors in my house every other week and trying to have a copy of all keys with friends or relatives living out of town.

[jesseendahl]

Account recovery flows are generally entirely unaffected by the move from password to passkey.

It’s just your login credential.

If you lose either a password or a passkey, you do the same thing: reset and set a new one via email recovery.

[lxgr]

> If you lose either a password or a passkey, you do the same thing: reset and set a new one via email recovery.

If that’s an option (and it often really is!), why go through all the trouble of implementing passkeys and not just implement “login via email”?

For some services, that’s not secure enough though.

[jesseendahl]

Account recovery flows are generally entirely unaffected by the move from password to passkey.

It’s just your login credential.

If you lose either a password or a passkey, you do the same thing: reset and set a new one via email recovery.

[reshlo]

Isn’t the whole point of a passkey that it’s meant to use a chain of trust to prove that you’re you via biometrics or a physical factor? I’ve read that they’re intended to remove the need for 2-factor authentication because they are both factors, which implies you shouldn’t be allowed to reset them.

Resetting 2-factor authentication by proving access to only one factor (email) defeats the purpose of requiring 2 factors. If they can be reset via email, they might as well not exist at all. Even if we assume that nobody other than the user has legitimate access to the emails sent to the user (which is often untrue), emails can be trivially intercepted by a third party.

Not to mention that if I’ve lost access to the device where I am signed in to my email account, I won’t be able to access my email account to reset my passkeys anyway, because access to my email account would also require a passkey that I no longer have.

[jesseendahl]

> Isn’t the whole point of a passkey that it’s meant to use a chain of trust to prove that you’re you via biometrics or a physical factor?

No actually! The biometric auth is more of a “liveness check” than anything else.

The point of passkeys is to replace the primary factor — the password — with a new primary factor that isn’t fundamentally “broken” in the ways passwords are. Password hashes can be stolen from servers, users frequently reuse them across different services, they are frequently very weak, and they are phishable. In contrast passkeys are guaranteed to be strong, unique, and there is nothing worth stealing from servers for attackers (only a public key).

[reshlo]

Many websites are using passkeys not as a primary factor, but as the second factor, or as both factors. That implies that they are meant to serve as some combination of “something you are” and “something you have”. The fact that you logged in with one by using biometrics proves both that you are you and that you have your phone. They’re certainly not “something you know” because they are designed specifically so that you are not allowed to know them.

Allowing both “something you are” and “something you have” to be reset simultaneously via proof only of “something you know” (the password to your email account) means that once that reset happens, you’ve gone from two or three factors to one factor.

Allowing passkeys to be reset by email is not compatible with using them as anything other than the primary factor. If you’re using them as both factors, you’d get equivalent security if you implemented sign-in via only magic links. If you’re using them as the second factor along with a password, but you allow them to be reset via email, you actually only have one factor.