6 ms·

Even though I work at a company that also supplies passkeys support to its customers, I feel it is worth for people to have a read of (1). The platform lock-in

by ffo 2y ago

Even though I work at a company that also supplies passkeys support to its customers, I feel it is worth for people to have a read of (1). The platform lock-in is a real problem we already see. Even password managers that sync the private key most of the times do not allow to export the key material. Oh, and if a customer ever wants to change the domain name for branding related stuff, is also where the fun starts. My 2 cents are that passwords/2fa, passkeys, federation and maybe soon verifiable credentials are concepts that will work for a long time in parallel. So, if you ever choose a system that does the "identity/authentication" plumbing work for you, I think you should focus solutions that are open source and allow you to mix and match the different concepts. IMO this applies to b2c and b2b alike ;-) [1] https://fy.blackhats.net.au/blog/2024-04-26-passkeys-a-shattered-dream/ https://fy.blackhats.net.au/blog/2024-04-26-passkeys-a-shatt...

growse 2y ago
> The platform lock-in is a real problem we already see. Even password managers that sync the private key most of the times do not allow to export the key material. I'm struggling a little bit with the use case here. Yubikeys and other HSMs also don't allow you to export the key material, and sites should have account recovery flows for people who lose access to their devices / HSMs / password manager databases. Is it merely a convenience thing, or is there an actual problem that can only be solved by allowing key material export?
- Macha 2y ago
  The difference is yubikeys have been mainly used in enterprise settings where the reset approach is "get IT to assign a new yubikey to your account or boot your old yubikey". Passkeys are aimed at the general consumer who has been a very rare user of the yubikey. Now you're back to trusting every user to physically keep track of their passkeys, rather than trusting a pool of IT admins.
- wkat4242 2y ago
  The export is important in case you want to move to a different service or password manager.
  - bayindirh 2y ago
    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 2y 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 2y 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.
- lrvick 2y ago
  You actually can backup your webauthn master seed with a Ledger as a 24 word phrase you write down.
- red_admiral 2y ago
  Yubikeys have a single master private key, and derive site-specific keys from that. It makes sense in this model not to allow key export. On the other hand, if you have 100 sites you log in to, you can use one key for everything. If you get a new computer, you can just carry on using the same key. If you lose or damage your key, admittedly things get harder. Passkeys are defined by at least one authority as "resident keys" in the sense that you have one key stored for each site. If you have more than one computer, or your old one breaks and you buy a new computer, you somehow have to get your 100 keys from A to B (and possibly keep them in sync). You could do this with a third-party cloud service (and pay subscription fees for it), but in this model it seems consumer-unfriendly to me to not allow me just to back up and transfer my own keys, especially when it's not possible on all sites to register more than one passkey in the first place. Even enterprise HSMs can do this to some extent with key-wrapping. (Yes, KeepassXC can do this too, but they've been threatened with a ban from the passkey ecosystem over this.) Personally, the way I'd like key-based authentication to work is something like how SSH keys work currently, where people who know what they're doing can set things up in a way that works efficiently for them. You can choose yourself whether you want 1:n or m:1 or m:n relationships between your keys and your sites and how to manage them.
  - formerly_proven 2y ago
    > (Yes, KeepassXC can do this too, but they've been threatened with a ban from the passkey ecosystem over this.) Bruh This is akin to CA/B Forum threatening to ban use of OpenSSL because it has a -nodes flag.
  - growse 2y ago
    > You could do this with a third-party cloud service (and pay subscription fees for it), but in this model it seems consumer-unfriendly to me to not allow me just to back up and transfer my own keys, especially when it's not possible on all sites to register more than one passkey in the first place. I get this, but I think it needs to be acknowledged that export presents a risk and that needs to be balanced. We might disagree with each other on which is more important, but I can certainly see a perspective that disallowing export (for a specific implementation) is more important than convenience. I'm also not sure to what extent the spec / implementers need to provide functionality to work around the fact that some sites are not implementing passkeys properly. That feels a bit icky.
- JakaJancar 2y ago
  The use case is that I’m an Apple/iCloud user and want to migrate to Google/Linux/whatever and don’t want to go to 100 sites manually to change my passkey?

by ffo 2y ago

growse 2y ago

> The platform lock-in is a real problem we already see. Even password managers that sync the private key most of the times do not allow to export the key material. I'm struggling a little bit with the use case here. Yubikeys and other HSMs also don't allow you to export the key material, and sites should have account recovery flows for people who lose access to their devices / HSMs / password manager databases. Is it merely a convenience thing, or is there an actual problem that can only be solved by allowing key material export?

Macha 2y ago
The difference is yubikeys have been mainly used in enterprise settings where the reset approach is "get IT to assign a new yubikey to your account or boot your old yubikey". Passkeys are aimed at the general consumer who has been a very rare user of the yubikey. Now you're back to trusting every user to physically keep track of their passkeys, rather than trusting a pool of IT admins.
wkat4242 2y ago
The export is important in case you want to move to a different service or password manager.
- bayindirh 2y ago
  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 2y 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 2y 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.
lrvick 2y ago
You actually can backup your webauthn master seed with a Ledger as a 24 word phrase you write down.
red_admiral 2y ago
Yubikeys have a single master private key, and derive site-specific keys from that. It makes sense in this model not to allow key export. On the other hand, if you have 100 sites you log in to, you can use one key for everything. If you get a new computer, you can just carry on using the same key. If you lose or damage your key, admittedly things get harder. Passkeys are defined by at least one authority as "resident keys" in the sense that you have one key stored for each site. If you have more than one computer, or your old one breaks and you buy a new computer, you somehow have to get your 100 keys from A to B (and possibly keep them in sync). You could do this with a third-party cloud service (and pay subscription fees for it), but in this model it seems consumer-unfriendly to me to not allow me just to back up and transfer my own keys, especially when it's not possible on all sites to register more than one passkey in the first place. Even enterprise HSMs can do this to some extent with key-wrapping. (Yes, KeepassXC can do this too, but they've been threatened with a ban from the passkey ecosystem over this.) Personally, the way I'd like key-based authentication to work is something like how SSH keys work currently, where people who know what they're doing can set things up in a way that works efficiently for them. You can choose yourself whether you want 1:n or m:1 or m:n relationships between your keys and your sites and how to manage them.
- formerly_proven 2y ago
  > (Yes, KeepassXC can do this too, but they've been threatened with a ban from the passkey ecosystem over this.) Bruh This is akin to CA/B Forum threatening to ban use of OpenSSL because it has a -nodes flag.
- growse 2y ago
  > You could do this with a third-party cloud service (and pay subscription fees for it), but in this model it seems consumer-unfriendly to me to not allow me just to back up and transfer my own keys, especially when it's not possible on all sites to register more than one passkey in the first place. I get this, but I think it needs to be acknowledged that export presents a risk and that needs to be balanced. We might disagree with each other on which is more important, but I can certainly see a perspective that disallowing export (for a specific implementation) is more important than convenience. I'm also not sure to what extent the spec / implementers need to provide functionality to work around the fact that some sites are not implementing passkeys properly. That feels a bit icky.
JakaJancar 2y ago
The use case is that I’m an Apple/iCloud user and want to migrate to Google/Linux/whatever and don’t want to go to 100 sites manually to change my passkey?