3 ms·

Why do you think it is reuse? You will not use the same passkey for multiple application/service. You will generate a passkey per application/service. I will

by ffo 2y ago

Why do you think it is reuse? You will not use the same passkey for multiple application/service. You will generate a passkey per application/service. I will certainly though not disagree on security... if that is your thing then do not sync private keys around, but the tradeoff is always there. If security would be critical, I would favor client certs with smartcards, but browsers do not support that "too well"

bayindirh 2y ago
If I share the same private key for an account with "n" devices, losing (incl. theft of) that key will lock me out. If I have "n" private keys for an account, I can use another private key and revoke the lost/compromised one. It's that simple. Your secure enclave is not much different electronically from a smart card with a biometric password actually. People think Passkeys as SSH keys on disk, but it's more of a long private key on a single-way secure enclave. This is why people cry "platform lock-in". It's platform lock-in, but it's a secondary effect. It's actually a "proper HSM, but integrated".
- ffo 2y ago
  Yes but the same logic about loosing the secret applies to passwords and any other factors (given we ignore a potential reset process) Providers will most of the time allow to register multiple passkeys or other authentication means, hopefully ;-) which has its own downsides. I am well aware how the internals work of keystores. But the benefit with "client certs" is that on mTLS you get added benefits besides where the key is stored. And that is that you can "prevent" mitm attacks. But I guess that is a subject for another thread.
  - formerly_proven 2y ago
    Resident passkeys really are just the 2020-JavaScript version of X.509-based mutual authentication - naturally it's incompatible with anything but the web, sits on a weird level of the stack, and is somehow even less transparent to the user. On the other hand, certificate slots still seem to run approximately a dollar each.
    - ffo 2y ago
      Haha comparison made me giggle.

by ffo 2y ago

bayindirh 2y ago

If I share the same private key for an account with "n" devices, losing (incl. theft of) that key will lock me out. If I have "n" private keys for an account, I can use another private key and revoke the lost/compromised one. It's that simple. Your secure enclave is not much different electronically from a smart card with a biometric password actually. People think Passkeys as SSH keys on disk, but it's more of a long private key on a single-way secure enclave. This is why people cry "platform lock-in". It's platform lock-in, but it's a secondary effect. It's actually a "proper HSM, but integrated".

ffo 2y ago
Yes but the same logic about loosing the secret applies to passwords and any other factors (given we ignore a potential reset process) Providers will most of the time allow to register multiple passkeys or other authentication means, hopefully ;-) which has its own downsides. I am well aware how the internals work of keystores. But the benefit with "client certs" is that on mTLS you get added benefits besides where the key is stored. And that is that you can "prevent" mitm attacks. But I guess that is a subject for another thread.
- formerly_proven 2y ago
  Resident passkeys really are just the 2020-JavaScript version of X.509-based mutual authentication - naturally it's incompatible with anything but the web, sits on a weird level of the stack, and is somehow even less transparent to the user. On the other hand, certificate slots still seem to run approximately a dollar each.
  - ffo 2y ago
    Haha comparison made me giggle.