3 ms·

In theory, You should be able to add a new passkey to your account, and remove the old one. Some of the physical security devices even doesn't support exportin

In theory, You should be able to add a new passkey to your account, and remove the old one. Some of the physical security devices even doesn't support exporting private keys. You ask something (encrypt/decrypt/sign) with a mailbox interface and you get the results. Key is never (and can't be) exposed outside of the secure enclave. Said keys are generated in an isolated RNG inside the key, too. So the system is completely self-contained. I understand the desire of flexibility and convenience, but this is a tradeoff on a slider. Some designs are full-in on security others are not. We should make choices according to that.

ffo 3y ago
I mean the question if private keys should be synced is the fun one to argue about ;-) My thinking is always if you do passkeys for phishing protection or potentially UX improvements then there is no harm syncing keys. (I would argue the security is increased by adding phishing protection over password/2fa) If you do it for security, then you do not want to sync keys and rely on key storage that do not allow extraction (most secure will be "offline" key stores like YubiKeys). I guess the latter is more important in enterprise/business scenarios rather than in b2c context. A little OT but it will also be fun in b2c explaining customers that there keystore is full on the hardware key. (of the top of my head YubiKey 5 have a limit of about 25 keys)
- bayindirh 3y ago
  If passkey is an additional factor, I'm on the same boat with you. You can sync them all the way down. But if it's the only factor, I can't see a difference between password reuse and passkey reuse. If I can recover it in any way, then it's (very) game over. So I'm not mad that you can't sync a passkey if it's the single factor. Because as we don't reuse app passwords for multiple devices or normal passwords for multiple sites, we shouldn't use the same private keys on many devices, allowing a more granular and better approach. Of course this is my view and some people won't agree. I prefer a good multi-layer system, not a single passkey opens the whole world style one.
  - ffo 3y 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 3y 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 3y 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 3y 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.
- WorldMaker 3y ago
  Perhaps what you are missing is the "middle ground" here because it is an implementation detail of some of the passkey implementations (especially some of the ones meant to be "consumer-resilient": derived keys. Rather than keeping every key for every site in hardware, you might use some secret shared between the hardware keys plus whatever site-specific salt/pepper/hash into some key derivation function (KDF). For those kinds of keys extraction is sort of meaningless: the private keys maybe aren't even stored at rest, they are re-derived as necessary. You can sync the encrypted shared secret and all the site-specific salt/pepper/hashes even to devices that can't decrypt them. (That's how secure but consumer-friendly syncing is built, and that's a part of how recovery pathways get built.) But it isn't useful on its own without the hardware keys that you can't themselves export. You can have syncing with the root keys being exportable/extractable. That's already how many of the consumer solutions are being built. That's part of where the consumer-friendly security is for Passkeys.
  - tatersolid 3y ago
    Deriving per-domain key pairs from a single master secret is what SQRL did, makes perfect sense for most use cases, allows for straightforward paper backup and transport between devices. https://www.grc.com/sqrl/sqrl.htm https://www.grc.com/sqrl/sqrl.htm
maple3142 3y ago
It sounds really really inconvenient when you have a lot of accounts on different websites. Imagine login to add new passkey andremove the old passkey for 100 websites (and my password manager already stores much more than 100 accounts).
- bayindirh 3y ago
  Yes, I'm aware that it's very inconvenient. I did the same for my TOTP codes because Google Authenticator didn't restore your keys if your devices were different. So, I had to manually migrate TOTP secrets from 30+ accounts back then, by removing 2FA, and re-enabling it with a new secret. As I said before, it's a sliding scale trading off between security and convenience. Select your poison and its dosage, and do your own cocktail. Or, providers will develop a workflow to migrate or add new devices easily. Like "validate on another validated device to add this new passkey" scheme.
  - wkat4242 3y ago
    I know, I use yubikeys for all my important stuff. But I view passkeys as more for the low-hanging fruit. All the crap accounts that every webshop and news outlet makes you create these days. I have 500+ accounts in my current password manager. Not being able to migrate that away to another service would be a nightmare. Being locked in with a big tech company would be too. What my ideal would be is to have the master key on multiple HSMs (like multiple yubikeys) so they are safe but mobile. Also, if software password managers don't offer export options it doesn't mean it's impossible to export. They just don't want to make it possible. But an adversary could. The only way to really make it impossible is hardware tokens which is great for important stuff but not really for those thirteen in a dozen accounts.
    - EvanAnderson 3y ago
      > What my ideal would be is to have the master key on multiple HSMs (like multiple yubikeys) so they are safe but mobile. That would be glorious. It would be great if it was standards-based, too, to prevent vendor lock-in.
growse 3y ago
I just looked on github (where I have 4 passkeys registered), and I noticed that the bitwarden one has a little "Synced" flag next to it. The tooltip says "This passkey is eligable for backup by its provider", so sites can distinguish between exportable ones and non-exportable ones.
- bayindirh 3y ago
  That's interesting information, thanks!
- tzs 3y ago
  That's different from what most people mean by "exportable", which is that the provider will give you a copy of the passkey which you can import into another provider. Syncable means that the provider can backup your passkey to someplace under their control, from whence they can restore it to a different device of yours where you also have that provider's client software. Here's how Github explains it [1] > Many passkeys support syncing, where your passkey is backed up by the provider's account system (iCloud, Google account, password manager, etc.). If you ever lose your device, you can recover your synced passkeys by signing in to your passkey provider. BTW, the flag on Github should probably say "Syncable" rather than "Synced". [1] https://docs.github.com/en/authentication/authenticating-with-a-passkey/managing-your-passkeys#recovering-a-passkey https://docs.github.com/en/authentication/authenticating-wit...

ffo 3y ago

I mean the question if private keys should be synced is the fun one to argue about ;-) My thinking is always if you do passkeys for phishing protection or potentially UX improvements then there is no harm syncing keys. (I would argue the security is increased by adding phishing protection over password/2fa) If you do it for security, then you do not want to sync keys and rely on key storage that do not allow extraction (most secure will be "offline" key stores like YubiKeys). I guess the latter is more important in enterprise/business scenarios rather than in b2c context. A little OT but it will also be fun in b2c explaining customers that there keystore is full on the hardware key. (of the top of my head YubiKey 5 have a limit of about 25 keys)

bayindirh 3y ago
If passkey is an additional factor, I'm on the same boat with you. You can sync them all the way down. But if it's the only factor, I can't see a difference between password reuse and passkey reuse. If I can recover it in any way, then it's (very) game over. So I'm not mad that you can't sync a passkey if it's the single factor. Because as we don't reuse app passwords for multiple devices or normal passwords for multiple sites, we shouldn't use the same private keys on many devices, allowing a more granular and better approach. Of course this is my view and some people won't agree. I prefer a good multi-layer system, not a single passkey opens the whole world style one.
- ffo 3y 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 3y 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 3y 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 3y 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.
WorldMaker 3y ago
Perhaps what you are missing is the "middle ground" here because it is an implementation detail of some of the passkey implementations (especially some of the ones meant to be "consumer-resilient": derived keys. Rather than keeping every key for every site in hardware, you might use some secret shared between the hardware keys plus whatever site-specific salt/pepper/hash into some key derivation function (KDF). For those kinds of keys extraction is sort of meaningless: the private keys maybe aren't even stored at rest, they are re-derived as necessary. You can sync the encrypted shared secret and all the site-specific salt/pepper/hashes even to devices that can't decrypt them. (That's how secure but consumer-friendly syncing is built, and that's a part of how recovery pathways get built.) But it isn't useful on its own without the hardware keys that you can't themselves export. You can have syncing with the root keys being exportable/extractable. That's already how many of the consumer solutions are being built. That's part of where the consumer-friendly security is for Passkeys.
- tatersolid 3y ago
  Deriving per-domain key pairs from a single master secret is what SQRL did, makes perfect sense for most use cases, allows for straightforward paper backup and transport between devices. https://www.grc.com/sqrl/sqrl.htm https://www.grc.com/sqrl/sqrl.htm

maple3142 3y ago

It sounds really really inconvenient when you have a lot of accounts on different websites. Imagine login to add new passkey andremove the old passkey for 100 websites (and my password manager already stores much more than 100 accounts).

bayindirh 3y ago
Yes, I'm aware that it's very inconvenient. I did the same for my TOTP codes because Google Authenticator didn't restore your keys if your devices were different. So, I had to manually migrate TOTP secrets from 30+ accounts back then, by removing 2FA, and re-enabling it with a new secret. As I said before, it's a sliding scale trading off between security and convenience. Select your poison and its dosage, and do your own cocktail. Or, providers will develop a workflow to migrate or add new devices easily. Like "validate on another validated device to add this new passkey" scheme.
- wkat4242 3y ago
  I know, I use yubikeys for all my important stuff. But I view passkeys as more for the low-hanging fruit. All the crap accounts that every webshop and news outlet makes you create these days. I have 500+ accounts in my current password manager. Not being able to migrate that away to another service would be a nightmare. Being locked in with a big tech company would be too. What my ideal would be is to have the master key on multiple HSMs (like multiple yubikeys) so they are safe but mobile. Also, if software password managers don't offer export options it doesn't mean it's impossible to export. They just don't want to make it possible. But an adversary could. The only way to really make it impossible is hardware tokens which is great for important stuff but not really for those thirteen in a dozen accounts.
  - EvanAnderson 3y ago
    > What my ideal would be is to have the master key on multiple HSMs (like multiple yubikeys) so they are safe but mobile. That would be glorious. It would be great if it was standards-based, too, to prevent vendor lock-in.

growse 3y ago

I just looked on github (where I have 4 passkeys registered), and I noticed that the bitwarden one has a little "Synced" flag next to it. The tooltip says "This passkey is eligable for backup by its provider", so sites can distinguish between exportable ones and non-exportable ones.

bayindirh 3y ago
That's interesting information, thanks!
tzs 3y ago
That's different from what most people mean by "exportable", which is that the provider will give you a copy of the passkey which you can import into another provider. Syncable means that the provider can backup your passkey to someplace under their control, from whence they can restore it to a different device of yours where you also have that provider's client software. Here's how Github explains it [1] > Many passkeys support syncing, where your passkey is backed up by the provider's account system (iCloud, Google account, password manager, etc.). If you ever lose your device, you can recover your synced passkeys by signing in to your passkey provider. BTW, the flag on Github should probably say "Syncable" rather than "Synced". [1] https://docs.github.com/en/authentication/authenticating-with-a-passkey/managing-your-passkeys#recovering-a-passkey https://docs.github.com/en/authentication/authenticating-wit...