So here's what stops me from using Passkeys.

- I want Passkeys.
- I want to use "BitWarden".
- BitWarden can use passkeys on all my platforms incl Android.
- However, I do not install BitWarden on all my computers, because I don't trust some of them to hold my BitWarden vault.
- This means I have to have a way of "airgapping" the passkey— some way of using a passkey on a phone, is a computer.
- The ONLY way to do this the FIDO Alliance allows requires Bluetooth.
- My computer doesn't have that.

I don't want to enable Bluetooth on my phone and I don't want to buy a Bluetooth card for my aging desktop. Moreover FIDO views "airgapping" as a security risk. They believe that banning "airgapping" is a necessary component of "anti-phishing", and "anti-phishing" is a highest-priority goal of the FIDO alliance. "Anti-phishing" is not a goal I have, but it is SO important to the FIDO alliance they'd rather I not use passkeys at all than me have passkeys but be allowed to airgap them.

So, here's my solution: Fork BitWarden, and fork its Firefox extension. Add some kind of special wifi handshake, that allows me to keep BitWarden on my phone, and have the passkey/password autofill on the untrusted computer's browser WebAuthn with passwords or passkeys as needed tunneled encrypted from the phone, and the traffic goes over TCP/IP rather than bluetooth.

I think this would work, and be safe but I think also the FIDO alliance would call what I'm doing here "phishing".

So I wonder about this. The thing I want is supposed to be impossible, and FIDO tries to put technical measures in place to make it impossible. But passkeys have been implemented by open source applications. So technically I don't see how they stop me.

There's another weird thing. [EDIT: removed outdated statement about Firefox support]; and the BitWarden site seems to imply Passkeys require Google Play Services. What? Problematic, as I am moving to Lineage or something soon.

Wait. Are Passkey apps literally banned from being properly open source?

https://peoplemaking.games/@leon/115663918924867641

If what Leon speculates here is the case, doesn't that imply you literally cannot write a GPL3-compliant Passkey implementation, as your build-time signing keys would have to be part of the chain of trust and this would violate the GPL3's rules against such signing keys being secret-but-mandatory?

Leon (@[email protected])

@[email protected] iirc an important part of the passkey system is attestation - the passkey wallet on the computer proves cryptographically it is made by who it’s said to be made by and is intact, so it hasn’t been compromised. This is enforced by a web of trust like HTTPS. For this reason I’m not sure forking bitwarden will result in a trustable passkey wallet, and something you should probably run to ground before investing time on imp.

People Making Games
@mcc attestation is optional and bitwarden afaik doesn't implement it anyway
@leo @q Huh that's worrying though because some of the sites I would like to sign into with via passkeys are companies (Google, Microsoft) who own and are actively trying to lock me into "software signing" ecosystems. So if attested keys are optional now, but could become non-optional in future, then that looks like a plausible future screw-turn for Google or Microsoft to attempt.
@mcc @q worth noting that the only thing i have seen that requires it is microsoft entra id and they're actively in the process of rolling out removing that requirement

@leo @q sure sure but

i'm thinking about the future

GitHub banned TOTP a few months ago with *one single weekend* of advance notice. They apparently are willing to move that quick.

@mcc @q preventing this from happening is why browsers display scary warnings when a site tries to use attestation, if google or microsoft wanted to change this they'd have to convince all browser vendors to change which seems unlikely
@mcc @leo no the warning is because attention allows, by its nature, device tracking
@q @mcc chromium commit messages say otherwise
@mcc @leo huh, curious. the debate in the standards bodies has always been over device tracking

@q @mcc @leo non-enterprise Yubikeys even go so far as to utilize "batch" certificates for attestation, where every device in that batch gets the same attestation secret, as a way to at least reduce tracking granularity, but even then "rough IP info" combined with that batch ID can get pretty unique pretty quickly...

(Enterprise ones can be provisioned with device-unique certs for various reasons that are all quite reasonable in that context)