4 ms·

The passkey spec authors think websites should be able to ban clients which allow users to manage their own data[1,2]. It makes me really hesitant to adopt pass

by coldpie 10mo ago

The passkey spec authors think websites should be able to ban clients which allow users to manage their own data[1,2]. It makes me really hesitant to adopt passkeys if my client could get banned because it's open source and lets me control my client how I want to. It appears to be more useful for vendor lock-in than anything else[3]. A shame, since it could've been a cool tech if they had built it to be resilient to this kind of abuse, but it's clear they think vendor lock-in is actually a core feature of the protocol. [1] Spec author quote: "To be very honest here, you risk having KeePassXC blocked by relying parties." https://github.com/keepassxreboot/keepassxc/issues/10407#issuecomment-1994182200 https://github.com/keepassxreboot/keepassxc/issues/10407#iss... [2] https://www.smokingonabike.com/2025/01/04/passkey-marketing-is-lying-to-you/ https://www.smokingonabike.com/2025/01/04/passkey-marketing-... [3] 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...

yawaramin 10mo ago
Apple doesn't do attestation, so effectively this feature is dead in the water.
- lelandbatey 10mo ago
  Per the article, Apple does do attestation. By default attestation is off unless you have enterprise management turned on. But the existence of attestation means Apple could at any time in the future make attestation on by default and suddenly our devices control our secrets more than we do.
  - raw_anon_1111 10mo ago
    Isn’t that just like people said in 2008 now that therd is a Mac App Store “any day now” that will be the only way to get apps on the Mac?
  - yawaramin 10mo ago
    No, Apple can't suddenly start doing attestation in the future by default because that would instantly kill all the passkeys that have already been created on Apple devices without attestation. It would be as if a home security company went around and changed all the locks they had installed on their customers' front doors. It would be instant suicide as a trusted vendor.
jeroenhd 10mo ago
The point of passkeys is that they're unexportable. Software implementations like Bitwarden/KeepassXC/etc. making them exportable go right against the point of the protocols. I personally think the ability to export+import passkeys is a good thing from a backup point of view, but he's not wrong in suggesting that companies actually using the high security features of passkeys will eventually block software implementations like these. This isn't about vendor lock-in. Nobody is asking for KeepassXC to remove passkey support. This is about security software implementing an API and not fulfilling the expectations that come with such an implementation. To quote the comment you linked: > That's fine. Let determined people do that, but don't make it easy for a user to be tricked into handing over all of their credentials in clear text.
- coldpie 10mo ago
  It's fine for them to make suggestions for projects to improve their software. The problem is threatening clients with being banned because they don't agree with those suggestions. If a website is able to ban me because of the passkey client I'm using, then I'm just not going to use passkeys. It's too unreliable. > personally think the ability to export+import passkeys is a good thing from a backup point of view It's not a "good thing," it's absolutely critical. If I can't back up my credentials in a location that I trust, then it's not an acceptable login method. What happens if my PC goes down and I couldn't export my data? I just can't log in anywhere? KeePassXC lets me do that, but the spec authors think it's appropriate to ban me for using it because it lets me manage my own data. That's bonkers.
  - jeroenhd 10mo ago
    I don't see where he is threatening anybody? He's just stating the obvious. If you promise to store a key in a non-exportable format and then create a big export button, websites won't trust your software. > What happens if my PC goes down and I couldn't export my data? I just can't log in anywhere? Then you follow the procedure you would follow for when you'd forget your password. Probably a password reset through email, maybe calling customer support. Or if you have it set up, you could use the passkey set up on your phone or Yubikey or whatever to log in and create a new password on your new PC. Passkeys aren't passwords, that's the whole point. It's modelled after the "something you have" factor, not "something you know". If you're finding workarounds to violate the security design, you're not gaining any advantage by using passkeys. Just use a password if you want to use a password.
otterley 10mo ago
So if a client ever goes rogue someday (either intentionally or has been compromised) and starts shipping off private material to a malicious third party, you think relying parties shouldn’t have the option not to trust that client anymore?
- pjc50 10mo ago
  Doesn't doing so necessarily lock out all the users using that client?
  - otterley 10mo ago
    It would, yes. Thus it’s an action I would only recommend if doing so would help prevent serious injury to their customers. If it comes down to a choice between locking a customer out and having, say, their money stolen, then the scale tips towards safety.
    - pjc50 10mo ago
      Perhaps, but then (as always) we're back to the security of the recovery workflow.
- coldpie 10mo ago
  Sure that's bad, but the trouble is you're not thinking about what the alternative is. If users don't have control over their own data, then someone else does. As stated by the spec authors on KeePassXC's bug tracker, open source software may be modified by the user, so cannot be trusted. The passkey proposal is for all of your keys to be managed by proprietary software validated by your phone or your computer's TPM module. That means one of three big, US-based tech companies will control all of the world's login data. Those 3 companies are all currently involved in the largest fascist-taint-tongue-polishing in US history, and we want to hand them control over the world's logins. That's a much, much bigger risk than some users doing something stupid. The spec needs to be written with the assumption that the user's private keystore may be hostile to the user's own interests, because in the real world, it is. It needs to be written to mitigate damage to the user from a hostile keystore. Instead, the spec places total trust in the keystore. This is a fatal error.

by coldpie 10mo ago

yawaramin 10mo ago

Apple doesn't do attestation, so effectively this feature is dead in the water.

lelandbatey 10mo ago
Per the article, Apple does do attestation. By default attestation is off unless you have enterprise management turned on. But the existence of attestation means Apple could at any time in the future make attestation on by default and suddenly our devices control our secrets more than we do.
- raw_anon_1111 10mo ago
  Isn’t that just like people said in 2008 now that therd is a Mac App Store “any day now” that will be the only way to get apps on the Mac?
- yawaramin 10mo ago
  No, Apple can't suddenly start doing attestation in the future by default because that would instantly kill all the passkeys that have already been created on Apple devices without attestation. It would be as if a home security company went around and changed all the locks they had installed on their customers' front doors. It would be instant suicide as a trusted vendor.

jeroenhd 10mo ago

The point of passkeys is that they're unexportable. Software implementations like Bitwarden/KeepassXC/etc. making them exportable go right against the point of the protocols. I personally think the ability to export+import passkeys is a good thing from a backup point of view, but he's not wrong in suggesting that companies actually using the high security features of passkeys will eventually block software implementations like these. This isn't about vendor lock-in. Nobody is asking for KeepassXC to remove passkey support. This is about security software implementing an API and not fulfilling the expectations that come with such an implementation. To quote the comment you linked: > That's fine. Let determined people do that, but don't make it easy for a user to be tricked into handing over all of their credentials in clear text.

coldpie 10mo ago
It's fine for them to make suggestions for projects to improve their software. The problem is threatening clients with being banned because they don't agree with those suggestions. If a website is able to ban me because of the passkey client I'm using, then I'm just not going to use passkeys. It's too unreliable. > personally think the ability to export+import passkeys is a good thing from a backup point of view It's not a "good thing," it's absolutely critical. If I can't back up my credentials in a location that I trust, then it's not an acceptable login method. What happens if my PC goes down and I couldn't export my data? I just can't log in anywhere? KeePassXC lets me do that, but the spec authors think it's appropriate to ban me for using it because it lets me manage my own data. That's bonkers.
- jeroenhd 10mo ago
  I don't see where he is threatening anybody? He's just stating the obvious. If you promise to store a key in a non-exportable format and then create a big export button, websites won't trust your software. > What happens if my PC goes down and I couldn't export my data? I just can't log in anywhere? Then you follow the procedure you would follow for when you'd forget your password. Probably a password reset through email, maybe calling customer support. Or if you have it set up, you could use the passkey set up on your phone or Yubikey or whatever to log in and create a new password on your new PC. Passkeys aren't passwords, that's the whole point. It's modelled after the "something you have" factor, not "something you know". If you're finding workarounds to violate the security design, you're not gaining any advantage by using passkeys. Just use a password if you want to use a password.

otterley 10mo ago

So if a client ever goes rogue someday (either intentionally or has been compromised) and starts shipping off private material to a malicious third party, you think relying parties shouldn’t have the option not to trust that client anymore?

pjc50 10mo ago
Doesn't doing so necessarily lock out all the users using that client?
- otterley 10mo ago
  It would, yes. Thus it’s an action I would only recommend if doing so would help prevent serious injury to their customers. If it comes down to a choice between locking a customer out and having, say, their money stolen, then the scale tips towards safety.
  - pjc50 10mo ago
    Perhaps, but then (as always) we're back to the security of the recovery workflow.
coldpie 10mo ago
Sure that's bad, but the trouble is you're not thinking about what the alternative is. If users don't have control over their own data, then someone else does. As stated by the spec authors on KeePassXC's bug tracker, open source software may be modified by the user, so cannot be trusted. The passkey proposal is for all of your keys to be managed by proprietary software validated by your phone or your computer's TPM module. That means one of three big, US-based tech companies will control all of the world's login data. Those 3 companies are all currently involved in the largest fascist-taint-tongue-polishing in US history, and we want to hand them control over the world's logins. That's a much, much bigger risk than some users doing something stupid. The spec needs to be written with the assumption that the user's private keystore may be hostile to the user's own interests, because in the real world, it is. It needs to be written to mitigate damage to the user from a hostile keystore. Instead, the spec places total trust in the keystore. This is a fatal error.