by altairprime | 2025-08-05 07:14:23+00:00
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.