3 ms·

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

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.

pseudalopex 2mo ago
People who say users should not be able to export keys are not confused. They believe users should not be able to export keys.
- Itoldmyselfso 2mo ago
  I was referring to confusion experienced by people new to the passkeys creating passkeys for the first time ("Where am I saving this to?", "How do I store this in my password manager?").
  - pseudalopex 2mo ago
    dotancohen would not be allowed to store Passkeys private keys in a Keepass database in the case thewebguyd specified. Relying parties would block password managers which allowed this.
  - ivlad 2mo ago
    You don’t. You don’t store anything at all. On registration, a keypair is generated, then the private key is encrypted with the long-term key burned into your security key fob or hardware. The encrypted blob is sent to the server and stored there. On authentication, after you enter your login, the server sends the encrypted blob and your security key tries to decrypt it with the long-term key it has. If it succeeds, it then request a challenge from the servers, signs it along with the server name and timestamp and sends back to the server. Server validates the signature and if it’s good, log you in. Expanded: As long you as the user has the security key fob, you can login. You should have 2.
    - doodlesdev 2mo ago
      > You don’t. You don’t store anything at all. Yes, you do. Whenever a website offers to create a passkey, it could end up in any of these: - Samsung's Password Manager (if using a Samsung phone) - Apple's Keychain (if using an iPhone) - Google Password Manager - Your operating system's keychain - A bespoke password manager (e.g., Bitwarden or LastPass) - Your hardware key Most users do not have a security key fob. Instead, the proposal being mostly pushed is the idea that users can store keys on their own smartphones, making use of the modern TPM and chip security. Most of the discussion here revolves around that idea: "What if I lose my phone? What if I switch phones?" and that's why the problems seem so obvious to you. I absolutely agree the best solution is to use hardware keys, but I'll admit it's cumbersome if I need them for hundreds of accounts (which I do have), having to register both for every website and praying that I never lose both at the same time in the case there's no viable recovery flow for some of the accounts. Also, most of these hardware keys are limited to 25 or 100 resident keys, which again makes them unable to substitute passwords. Observe the usage of the term resident keys: passkeys do rely on the private key being stored on the hardware key, as that allows discovery.
      - ivlad 2mo ago
        I was talking about the non-resident FIDO keys. “Passkey” term is meaningless unfortunately because FIDO Alliance did not define it initially, it was a marketing term invented by Apple and then re-introduced (or shoved down the throat) by the FIDO alliance. In non-resident keys scenario you don’t store anything and from what I see there is no security downside of using non-resident keys. Loosing both (or multiple) security keys is like loosing all your car or home keys. Very inconvenient, agreed. Anyway, I think we can agree that FIDO authentication protocol implementation is a mess. Apple and Google made it messy because they wanted to lock down users to their platforms and then password managers followed. As a result, the current implementation is not more secure than “login with Apple” or “login with Google”.
        doodlesdev 2mo ago
        I agree! Indeed, the only advantage to Resident Keys (i.e., Passkeys) is the discoverabillity of them, so you can login without even using a username. It's a shame all of the terminology around WebAuthn/FIDO2 and Passkeys is so loose and badly defined. Honestly, I think OAuth logins are still an ok option for the average user, unfortunately, as I would never recommend someone I love to use Passkeys and put them through the burden of having to understand and deal with all of this mess.

pseudalopex 2mo ago

People who say users should not be able to export keys are not confused. They believe users should not be able to export keys.

Itoldmyselfso 2mo ago
I was referring to confusion experienced by people new to the passkeys creating passkeys for the first time ("Where am I saving this to?", "How do I store this in my password manager?").
- pseudalopex 2mo ago
  dotancohen would not be allowed to store Passkeys private keys in a Keepass database in the case thewebguyd specified. Relying parties would block password managers which allowed this.
- ivlad 2mo ago
  You don’t. You don’t store anything at all. On registration, a keypair is generated, then the private key is encrypted with the long-term key burned into your security key fob or hardware. The encrypted blob is sent to the server and stored there. On authentication, after you enter your login, the server sends the encrypted blob and your security key tries to decrypt it with the long-term key it has. If it succeeds, it then request a challenge from the servers, signs it along with the server name and timestamp and sends back to the server. Server validates the signature and if it’s good, log you in. Expanded: As long you as the user has the security key fob, you can login. You should have 2.
  - doodlesdev 2mo ago
    > You don’t. You don’t store anything at all. Yes, you do. Whenever a website offers to create a passkey, it could end up in any of these: - Samsung's Password Manager (if using a Samsung phone) - Apple's Keychain (if using an iPhone) - Google Password Manager - Your operating system's keychain - A bespoke password manager (e.g., Bitwarden or LastPass) - Your hardware key Most users do not have a security key fob. Instead, the proposal being mostly pushed is the idea that users can store keys on their own smartphones, making use of the modern TPM and chip security. Most of the discussion here revolves around that idea: "What if I lose my phone? What if I switch phones?" and that's why the problems seem so obvious to you. I absolutely agree the best solution is to use hardware keys, but I'll admit it's cumbersome if I need them for hundreds of accounts (which I do have), having to register both for every website and praying that I never lose both at the same time in the case there's no viable recovery flow for some of the accounts. Also, most of these hardware keys are limited to 25 or 100 resident keys, which again makes them unable to substitute passwords. Observe the usage of the term resident keys: passkeys do rely on the private key being stored on the hardware key, as that allows discovery.
    - ivlad 2mo ago
      I was talking about the non-resident FIDO keys. “Passkey” term is meaningless unfortunately because FIDO Alliance did not define it initially, it was a marketing term invented by Apple and then re-introduced (or shoved down the throat) by the FIDO alliance. In non-resident keys scenario you don’t store anything and from what I see there is no security downside of using non-resident keys. Loosing both (or multiple) security keys is like loosing all your car or home keys. Very inconvenient, agreed. Anyway, I think we can agree that FIDO authentication protocol implementation is a mess. Apple and Google made it messy because they wanted to lock down users to their platforms and then password managers followed. As a result, the current implementation is not more secure than “login with Apple” or “login with Google”.
      - doodlesdev 2mo ago
        I agree! Indeed, the only advantage to Resident Keys (i.e., Passkeys) is the discoverabillity of them, so you can login without even using a username. It's a shame all of the terminology around WebAuthn/FIDO2 and Passkeys is so loose and badly defined. Honestly, I think OAuth logins are still an ok option for the average user, unfortunately, as I would never recommend someone I love to use Passkeys and put them through the burden of having to understand and deal with all of this mess.