4 ms·

Passkeys are another brick in this wall. The authors of the spec built in client software identification and attestation, which means authenticating parties ca

Passkeys are another brick in this wall. The authors of the spec built in client software identification and attestation, which means authenticating parties can require you to only use certain, closed-source passkey clients. It's not hard to imagine a future where only blessed Passkey clients, such as Microsoft's, Apple's, and Google's implementations, are allowed by most services.

elric 1y ago
Heh, I'm working on a blog post about this very topic. Passkeys are ... weird. There's a lot of potential for gatekeeping, where websites can indeed require you to use device-bound passkeys through device attestation, and where becoming a vendor requires interacting with the fido alliance.... I would say "I'm sure the mean well", but given that parties like Yubico benefit from not getting more competitors, the cynic in me is a bit worried.
- coldpie 1y ago
  > I would say "I'm sure they mean well", Yeah, I wouldn't say that. It's clear from their public comments[1,2,3] that the spec authors don't believe the private key actually belongs to the user to do what they want with. They see services restricting what users may do with their own logins as a feature of Passkeys. It's really a shame it went in this direction. Replacing passwords with an easy-to-use keypair auth system would be a massive security improvement. But the Passkey ecosystem is poisoned at this point. Unless they remove the client ID & attestation anti-features, it should be considered a proprietary big tech protocol. [1] Threatening an open-source passkey client with server-side bans because they don't implement passkey storage on the client device in the way the spec authors prefer. https://github.com/keepassxreboot/keepassxc/issues/10406 https://github.com/keepassxreboot/keepassxc/issues/10406 [2] Maintaining a list of "non-compliant" clients, including the above open-source one, presumably for use in server-side bans. https://passkeys.dev/docs/reference/known-issues/ https://passkeys.dev/docs/reference/known-issues/ [3] While writing an article about this on my website, I actually emailed the two involved spec authors on the above issue, politely asking how their interpretation of the Passkey spec could possibly be compatible with open source software. Neither replied.
  - rcxdude 1y ago
    It is particularly odd in the case of open-source clients (or indeed any client that runs outside of some very locked down hardware) because a) there's nothing that prevents the user exfiltrating keys anyway, and b) attestation also means relatively little for such an implementation.
    - coldpie 1y ago
      Yes, the problems are obvious and the spec authors definitely know & understand the issues. Their refusal to have a public discussion about it indicates they just don't care, and their maintenance of a "naughty client list" shows Passkeys are intentionally hostile to user freedom.
bakies 1y ago
Yeah I hate this, installed a new CPU and none of my passkeys work. The browser asks my phone and they don't trust each other and not a damn clue how to fix it.
- coldpie 1y ago
  You could have used an open source client to manage your passkeys as you like, including backing them up in your own storage format. I wrote about it here: <https://www.smokingonabike.com/2025/01/04/passkey-marketing-is-lying-to-you/ https://www.smokingonabike.com/2025/01/04/passkey-marketing-...> I was quite excited about it... until I found out that the Passkey spec authors have warned that client that it may face server-side bans because it lets you manage your own private key how you want, and the spec authors think this is appropriate for servers to do. So I deleted all my Passkeys. Sigh.
  - elric 1y ago
    Reading these comments, I'm happy to see that I'm not the only passkey skeptic.
    - coldpie 1y ago
      You'll probably enjoy this article from one of the original creators of the Passkey ecosystem: > Since then Passkeys are now seen as a way to capture users and audiences into a platform. What better way to encourage long term entrapment of users then by locking all their credentials into your platform, and even better, credentials that can't be extracted or exported in any capacity. 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... Fingers crossed the Passkey user experience remains so bad no one accepts them & they just die on the vine.
- rcxdude 1y ago
  Yep, big problem with them: most users have no idea where the thing that pops up and offers to store the passkeys actually stores them (sounds like in your case, in your computer's TPM was either on the CPU you replaced or complained and reset itself when the CPU changed). It's a ticking timebomb that all the 'users love passkeys! (after we nag them about it every time they login until they give up)' blogs fail to catch.
walterbell 1y ago
Password managers are regulated as "important" software under EU CRA (Dec 2027).
- elric 1y ago
  Thankfully open source software is not subject to that, so FOSS password managers should be fine. Doesn't mean that other forces won't try to tear them down, however.
  - walterbell 1y ago
    See the fine print, https://news.ycombinator.com/item?id=45718665#45722286 https://news.ycombinator.com/item?id=45718665#45722286
donmcronald 1y ago
I think passkeys will be used against users. They’ll be used to attest to a user’s trustworthiness by tying authentication back to a real identity. Like another comment mentioned, you’ll end up needing something like a phone that’s locked down. Part of that will be authenticating with a verified ID IMO. It’ll be incredibly easy to lock dissenters out of modern society. It’s too bad the vast majority of users will happily concede autonomy for a tiny bit of short term convenience.
- rcxdude 1y ago
  I expect there will be backlash from non-technical users due to issues like the comment below where the passkey pushers fail to communicate where the keys are stored and thus users unexpectedly lose access to them.

elric 1y ago

Heh, I'm working on a blog post about this very topic. Passkeys are ... weird. There's a lot of potential for gatekeeping, where websites can indeed require you to use device-bound passkeys through device attestation, and where becoming a vendor requires interacting with the fido alliance.... I would say "I'm sure the mean well", but given that parties like Yubico benefit from not getting more competitors, the cynic in me is a bit worried.

coldpie 1y ago
> I would say "I'm sure they mean well", Yeah, I wouldn't say that. It's clear from their public comments[1,2,3] that the spec authors don't believe the private key actually belongs to the user to do what they want with. They see services restricting what users may do with their own logins as a feature of Passkeys. It's really a shame it went in this direction. Replacing passwords with an easy-to-use keypair auth system would be a massive security improvement. But the Passkey ecosystem is poisoned at this point. Unless they remove the client ID & attestation anti-features, it should be considered a proprietary big tech protocol. [1] Threatening an open-source passkey client with server-side bans because they don't implement passkey storage on the client device in the way the spec authors prefer. https://github.com/keepassxreboot/keepassxc/issues/10406 https://github.com/keepassxreboot/keepassxc/issues/10406 [2] Maintaining a list of "non-compliant" clients, including the above open-source one, presumably for use in server-side bans. https://passkeys.dev/docs/reference/known-issues/ https://passkeys.dev/docs/reference/known-issues/ [3] While writing an article about this on my website, I actually emailed the two involved spec authors on the above issue, politely asking how their interpretation of the Passkey spec could possibly be compatible with open source software. Neither replied.
- rcxdude 1y ago
  It is particularly odd in the case of open-source clients (or indeed any client that runs outside of some very locked down hardware) because a) there's nothing that prevents the user exfiltrating keys anyway, and b) attestation also means relatively little for such an implementation.
  - coldpie 1y ago
    Yes, the problems are obvious and the spec authors definitely know & understand the issues. Their refusal to have a public discussion about it indicates they just don't care, and their maintenance of a "naughty client list" shows Passkeys are intentionally hostile to user freedom.

bakies 1y ago

Yeah I hate this, installed a new CPU and none of my passkeys work. The browser asks my phone and they don't trust each other and not a damn clue how to fix it.

coldpie 1y ago
You could have used an open source client to manage your passkeys as you like, including backing them up in your own storage format. I wrote about it here: <https://www.smokingonabike.com/2025/01/04/passkey-marketing-is-lying-to-you/ https://www.smokingonabike.com/2025/01/04/passkey-marketing-...> I was quite excited about it... until I found out that the Passkey spec authors have warned that client that it may face server-side bans because it lets you manage your own private key how you want, and the spec authors think this is appropriate for servers to do. So I deleted all my Passkeys. Sigh.
- elric 1y ago
  Reading these comments, I'm happy to see that I'm not the only passkey skeptic.
  - coldpie 1y ago
    You'll probably enjoy this article from one of the original creators of the Passkey ecosystem: > Since then Passkeys are now seen as a way to capture users and audiences into a platform. What better way to encourage long term entrapment of users then by locking all their credentials into your platform, and even better, credentials that can't be extracted or exported in any capacity. 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... Fingers crossed the Passkey user experience remains so bad no one accepts them & they just die on the vine.
rcxdude 1y ago
Yep, big problem with them: most users have no idea where the thing that pops up and offers to store the passkeys actually stores them (sounds like in your case, in your computer's TPM was either on the CPU you replaced or complained and reset itself when the CPU changed). It's a ticking timebomb that all the 'users love passkeys! (after we nag them about it every time they login until they give up)' blogs fail to catch.

walterbell 1y ago

Password managers are regulated as "important" software under EU CRA (Dec 2027).

elric 1y ago
Thankfully open source software is not subject to that, so FOSS password managers should be fine. Doesn't mean that other forces won't try to tear them down, however.
- walterbell 1y ago
  See the fine print, https://news.ycombinator.com/item?id=45718665#45722286 https://news.ycombinator.com/item?id=45718665#45722286

donmcronald 1y ago

I think passkeys will be used against users. They’ll be used to attest to a user’s trustworthiness by tying authentication back to a real identity. Like another comment mentioned, you’ll end up needing something like a phone that’s locked down. Part of that will be authenticating with a verified ID IMO. It’ll be incredibly easy to lock dissenters out of modern society. It’s too bad the vast majority of users will happily concede autonomy for a tiny bit of short term convenience.

rcxdude 1y ago
I expect there will be backlash from non-technical users due to issues like the comment below where the passkey pushers fail to communicate where the keys are stored and thus users unexpectedly lose access to them.