6 ms·

They're working on a secure exchange format between managers: https://fidoalliance.org/specifications-credential-exchange-specifications/ https://fidoalliance.o

They're working on a secure exchange format between managers: https://fidoalliance.org/specifications-credential-exchange-specifications/ https://fidoalliance.org/specifications-credential-exchange-...

marcosdumay 1y ago
It has been on the HN frontpage before. By "secure" understand "from the user escaping big corpos", and one that the most used open source project was already rejected from because open source is just not compatible with it.
- altairprime 1y ago
  Open source isn’t compatible if it isn’t running in a secure attestation environment, because 1) people will modify it to be more convenient and less secure; and then 2) they’ll transfer keys from their HSM into plaintext. I’ve watched extremely competent developers spend months figuring out how to bypass second-device factors in order to have a more convenient workflow with their auth key stored in cleartext in a dot file. I know without a shadow of a doubt that if unattested open source was allowed to interop with passkeys, they’d abuse that just as readily in order to be free of the restrictions that HSM-mandatory storage carries. Whatever the “most used open source project” you’re referring to is, all they need to do* is issue a 100%-reproducible binary that they then sign with their usual signing key. Once they submit that build for an independent audit and have it verified as not secretly backdoored, then the other password managers can trust it when secure boot attestation chains all the way down to their signature. This maintains the key benefits of open source — inspectability, pull requests, and so on — while adhering the specifications of PassKeys that protect them against expert users. The password manager, whoever they are, would have likely figured this opportunity out on their own and then rejected it. I can’t be sure, though. Perhaps they didn’t realize it was possible! Or perhaps they opted out of participating. Whatever the case, that’s not any fault of open source. It’s the fault of signatures: no binary is going to be permitted to exchange PassKeys unless it's signed by a trusted party adhering to the PassKeys ‘HSM only’ agreements. Whether their signed binary is reproducible open source or pure binary closed source is irrelevant in an attested environment. No user-modifiable solution will ever be acceptable? Unless reproducible builds and audited modifications. But that’s not an open source problem. I have extensive Ghidra experience and source code is certainly no significant obstacle to extracting passwords. Source code is irrelevant to the problem; signatures, attestation, and secure boot are the key. It would be perfectly reasonable for a consortium of no-cost, no-profit, open source password managers to jointly accept each other’s PassKeys for transfer under attested conditions — and if they did so genuinely without it being backdoored, then that would be a convincing argument both as an alternative to the ‘corporate’ passkeys system, as well as a convincing argument for W3C and the corporations to accept interop with their signed binaries under attested conditions rather than see the PassKeys ecosystem splinter. Certainly the W3C would pressure for their acceptance if their intentions were genuine :) A useful analogy is blackhat badges. Whether the badge is open source or not has no impact on that blackhat requires an attestation from someone other than you that you’re welcome at the conference. Having source code is like having a badge schematic in this analogy: there are lots of good outcomes from it, but gatecrashing without agreeing to their rules isn’t welcome. * Assuming that they want to pass at all, as opposed to taking some sort of hard stance against the core precept of PassKeys: i.e. “the user can’t be trusted, even if they’re an expert”. But, again, that’s nothing to do with open source.
  - rcxdude 1y ago
    I'm sorry, this is an absolute monstrous attitude towards user freedom in the name of security. There is no way I'm using passkeys if this is what they're about.
    - altairprime 1y ago
      No need to apologize to me. Raising awareness is my mission goal for discussing attestation at HN. Not to promote it — there’s one specific use case for it that I think is firmly appropriate and PassKeys isn’t that! — but to ensure that people are informed about what’s going on so that it can be evaluated face-on.
    - eyeris 1y ago
      Believe this is the goal of pushing towards secure compute like Google’s SafetyNet or Windows 11 with tpm. Feels like there are some more thematic underpinnings as well like security at the cost of user freedom or at the cost of tinker-ability.
      - altairprime 1y ago
        The Windows 11 TPM push parallels macOS and the T2 chip, except years later. Once Win11 is in the majority, I imagine web attestation will start to go live in web banking, because they hate paying for fraud investigations. But. The silent looming threat I predict that few others seem to see, is that Valve will guaranteed enable TPM w/ secure boot attestation in a future Steam Deck hardware update after everyone bails from Windows 10 to Valve Linux, giving it true standing as a console and overcoming today’s multiplayer lockouts by AAA games (unattested Linux is a godsend for software cheaters compared to Windows), while having captured that market on the pretense of tinkerability with full intentions to betray that unstated assumption in favor of regaining AAA multiplayer support in games. Similarly, that’s why so many AMD gaming processors already ship with Microsoft’s secure attestation Proton chip from the Xbox inside: if Microsoft wants to end kernel-rootkit anticheat, they have to offer another solution, or else competitive PC multiplayer online gaming dies when Microsoft slams the door on Crowdstrike. Secure attestation, coming to a Steam instance near you. (And not to single out Valve — Epic will go there too!) Console-grade attestation is coming to computers everywhere, because just as with password theft, it uniformly prevents virtually all software-based cheating. It won’t stop hardware-based cheating, but doi:10.1109/SERE-C.2012.43 and Apple mFI already demonstrated that peripheral attestation can arrive at any time — there just isn’t any point in doing so for Win/Lin gaming when most users aren’t using attestation. Yet. Sometimes I feel like Chicken Little trying to convey the threat to repurposeability here, but, like, this is what’s coming, because after the Crowdstrike worldwide outage, kernel rootkits are on the way out - and the side effects are going to be devastating. This is why I don’t just say, as one comment below does, “fuck you” to attestation: that approach has no effect and it’s coming for everyone unless more people than I start confronting it and understanding it.
politelemon 1y ago
This looks entirely optional and at the discretion of the provider, and not part of the spec itself. Please correct it that's wrong.
scarab92 1y ago
Passkeys seem like a kludge. A single per-user client certificate is a cleaner solution, without the vendor lock in problem, since there’s no need for real time synchronisation of an evolving set of passkeys.
- crote 1y ago
  Having a single certificate makes it trivial to implement cross-website tracking. FIDO2 (and by extension Passkeys) prevent this by having a unique key for every (origin, username) combination. Also, having a single cert shared across multiple hardware tokens is a security risk, as it becomes impossible to distinguish the tokens or revoke only a single one of them.
  - scarab92 1y ago
    The vast majority of users treat their set of passkeys as a unit anyway, so there’s no scenario when a single token would need to be revoked in isolation. A breach of one passkey can only occur from breaching the password manager itself, in which case all passkeys are exposed, so there’s no security benefit to having per site passkeys. Users who truly need that ability can create multiple certificates, and synchronise them as appropriate.
    - bananapub 1y ago
      perhaps this a good moment for you to engage in some reflection and consider that perhaps some people have put more thought in to "how do we replace passwords" than you did in making a single hacker news comment? you: > A single per-user client certificate is a cleaner solution, without the vendor lock in problem, since there’s no need for real time synchronisation of an evolving set of passkeys. reply: > Having a single certificate makes it trivial to implement cross-website tracking. you: > Users who truly need that ability can create multiple certificates, and synchronise them as appropriate. well, indeed! perhaps designing a system to support multiple certificates with synchronisation, so that we're not forcing ever user to be trackable by every single website, would be a good idea. some sort of keys to enable one's passage in to a website? this is a cancer on this website, and certainly one I'm also suffering from, despite being quite aware of it - real life things are usually pretty complicated and just because I know enough to make a random guess at a solution, it doesn't mean people who have put way thought in to the problem have done a bad job or missed by brilliant insight.
mathiaspoint 1y ago
Get rid of the CA-style provider certification and let me implement the API directly, myself, with just Python or a C compiler. Until you do that it's corpo malware and I will live in a tent in the woods before I use it.
- timmyc123 1y ago
  This is exactly what exists today. There is no "CA-style provider certification" in the synced passkey ecosystem. It is completely open.

marcosdumay 1y ago

It has been on the HN frontpage before. By "secure" understand "from the user escaping big corpos", and one that the most used open source project was already rejected from because open source is just not compatible with it.

altairprime 1y ago
Open source isn’t compatible if it isn’t running in a secure attestation environment, because 1) people will modify it to be more convenient and less secure; and then 2) they’ll transfer keys from their HSM into plaintext. I’ve watched extremely competent developers spend months figuring out how to bypass second-device factors in order to have a more convenient workflow with their auth key stored in cleartext in a dot file. I know without a shadow of a doubt that if unattested open source was allowed to interop with passkeys, they’d abuse that just as readily in order to be free of the restrictions that HSM-mandatory storage carries. Whatever the “most used open source project” you’re referring to is, all they need to do* is issue a 100%-reproducible binary that they then sign with their usual signing key. Once they submit that build for an independent audit and have it verified as not secretly backdoored, then the other password managers can trust it when secure boot attestation chains all the way down to their signature. This maintains the key benefits of open source — inspectability, pull requests, and so on — while adhering the specifications of PassKeys that protect them against expert users. The password manager, whoever they are, would have likely figured this opportunity out on their own and then rejected it. I can’t be sure, though. Perhaps they didn’t realize it was possible! Or perhaps they opted out of participating. Whatever the case, that’s not any fault of open source. It’s the fault of signatures: no binary is going to be permitted to exchange PassKeys unless it's signed by a trusted party adhering to the PassKeys ‘HSM only’ agreements. Whether their signed binary is reproducible open source or pure binary closed source is irrelevant in an attested environment. No user-modifiable solution will ever be acceptable? Unless reproducible builds and audited modifications. But that’s not an open source problem. I have extensive Ghidra experience and source code is certainly no significant obstacle to extracting passwords. Source code is irrelevant to the problem; signatures, attestation, and secure boot are the key. It would be perfectly reasonable for a consortium of no-cost, no-profit, open source password managers to jointly accept each other’s PassKeys for transfer under attested conditions — and if they did so genuinely without it being backdoored, then that would be a convincing argument both as an alternative to the ‘corporate’ passkeys system, as well as a convincing argument for W3C and the corporations to accept interop with their signed binaries under attested conditions rather than see the PassKeys ecosystem splinter. Certainly the W3C would pressure for their acceptance if their intentions were genuine :) A useful analogy is blackhat badges. Whether the badge is open source or not has no impact on that blackhat requires an attestation from someone other than you that you’re welcome at the conference. Having source code is like having a badge schematic in this analogy: there are lots of good outcomes from it, but gatecrashing without agreeing to their rules isn’t welcome. * Assuming that they want to pass at all, as opposed to taking some sort of hard stance against the core precept of PassKeys: i.e. “the user can’t be trusted, even if they’re an expert”. But, again, that’s nothing to do with open source.
- rcxdude 1y ago
  I'm sorry, this is an absolute monstrous attitude towards user freedom in the name of security. There is no way I'm using passkeys if this is what they're about.
  - altairprime 1y ago
    No need to apologize to me. Raising awareness is my mission goal for discussing attestation at HN. Not to promote it — there’s one specific use case for it that I think is firmly appropriate and PassKeys isn’t that! — but to ensure that people are informed about what’s going on so that it can be evaluated face-on.
  - eyeris 1y ago
    Believe this is the goal of pushing towards secure compute like Google’s SafetyNet or Windows 11 with tpm. Feels like there are some more thematic underpinnings as well like security at the cost of user freedom or at the cost of tinker-ability.
    - altairprime 1y ago
      The Windows 11 TPM push parallels macOS and the T2 chip, except years later. Once Win11 is in the majority, I imagine web attestation will start to go live in web banking, because they hate paying for fraud investigations. But. The silent looming threat I predict that few others seem to see, is that Valve will guaranteed enable TPM w/ secure boot attestation in a future Steam Deck hardware update after everyone bails from Windows 10 to Valve Linux, giving it true standing as a console and overcoming today’s multiplayer lockouts by AAA games (unattested Linux is a godsend for software cheaters compared to Windows), while having captured that market on the pretense of tinkerability with full intentions to betray that unstated assumption in favor of regaining AAA multiplayer support in games. Similarly, that’s why so many AMD gaming processors already ship with Microsoft’s secure attestation Proton chip from the Xbox inside: if Microsoft wants to end kernel-rootkit anticheat, they have to offer another solution, or else competitive PC multiplayer online gaming dies when Microsoft slams the door on Crowdstrike. Secure attestation, coming to a Steam instance near you. (And not to single out Valve — Epic will go there too!) Console-grade attestation is coming to computers everywhere, because just as with password theft, it uniformly prevents virtually all software-based cheating. It won’t stop hardware-based cheating, but doi:10.1109/SERE-C.2012.43 and Apple mFI already demonstrated that peripheral attestation can arrive at any time — there just isn’t any point in doing so for Win/Lin gaming when most users aren’t using attestation. Yet. Sometimes I feel like Chicken Little trying to convey the threat to repurposeability here, but, like, this is what’s coming, because after the Crowdstrike worldwide outage, kernel rootkits are on the way out - and the side effects are going to be devastating. This is why I don’t just say, as one comment below does, “fuck you” to attestation: that approach has no effect and it’s coming for everyone unless more people than I start confronting it and understanding it.

politelemon 1y ago

This looks entirely optional and at the discretion of the provider, and not part of the spec itself. Please correct it that's wrong.

scarab92 1y ago

Passkeys seem like a kludge. A single per-user client certificate is a cleaner solution, without the vendor lock in problem, since there’s no need for real time synchronisation of an evolving set of passkeys.

crote 1y ago
Having a single certificate makes it trivial to implement cross-website tracking. FIDO2 (and by extension Passkeys) prevent this by having a unique key for every (origin, username) combination. Also, having a single cert shared across multiple hardware tokens is a security risk, as it becomes impossible to distinguish the tokens or revoke only a single one of them.
- scarab92 1y ago
  The vast majority of users treat their set of passkeys as a unit anyway, so there’s no scenario when a single token would need to be revoked in isolation. A breach of one passkey can only occur from breaching the password manager itself, in which case all passkeys are exposed, so there’s no security benefit to having per site passkeys. Users who truly need that ability can create multiple certificates, and synchronise them as appropriate.
  - bananapub 1y ago
    perhaps this a good moment for you to engage in some reflection and consider that perhaps some people have put more thought in to "how do we replace passwords" than you did in making a single hacker news comment? you: > A single per-user client certificate is a cleaner solution, without the vendor lock in problem, since there’s no need for real time synchronisation of an evolving set of passkeys. reply: > Having a single certificate makes it trivial to implement cross-website tracking. you: > Users who truly need that ability can create multiple certificates, and synchronise them as appropriate. well, indeed! perhaps designing a system to support multiple certificates with synchronisation, so that we're not forcing ever user to be trackable by every single website, would be a good idea. some sort of keys to enable one's passage in to a website? this is a cancer on this website, and certainly one I'm also suffering from, despite being quite aware of it - real life things are usually pretty complicated and just because I know enough to make a random guess at a solution, it doesn't mean people who have put way thought in to the problem have done a bad job or missed by brilliant insight.

mathiaspoint 1y ago

Get rid of the CA-style provider certification and let me implement the API directly, myself, with just Python or a C compiler. Until you do that it's corpo malware and I will live in a tent in the woods before I use it.

timmyc123 1y ago
This is exactly what exists today. There is no "CA-style provider certification" in the synced passkey ecosystem. It is completely open.