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 I have never seen a website require an attested passkey outside of very specific circumstances
@q @mcc yeah fuck vendor attestation, acab includes yubico
@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
@mcc @q i'm not sure google's passkey implementation even has it? i think windows hello does, and yubikeys definitely do

@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 (and as @q said apple disables attestation entirely by default, only allowing it to be enabled via mdm)
@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)

@leo @q thank you for explaining
@mcc @leo @q do you have a source for GitHub banning TOTP? I have TOTP on my GitHub account, and I just signed out and back in using a TOTP to verify that it still works. I would claim that GitHub did not ban TOTP, but maybe you have different information?

@ryanprior @leo @q I was incorrect. Straight up incorrect.

It was NPM that did it. Source:

https://digipres.club/@misty/115664180577700824

My sense was that they did this as a panic response to a single NPM supply chain attack incident.

Misty (@[email protected])

@[email protected] The weird part for me here - *npm*, owned by GitHub, banned TOTP. GitHub, as far as I can tell, didn't. (It's still available in the UI and the docs have no warnings telling you not to use it.) So I suppose I can conclude that TOTP is insecure when you use it for npm and not when you use it for GitHub, according to Microsoft. https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/about-two-factor-authentication

digipres.club
@mcc @leo @q I wonder if they learned that a threat actor was using a specific spear phishing technique targeting npm maintainers that defeats TOTP. Or maybe it's arbitrary, I dunno, Microsoft is a big chaotic place.
@mcc The weird part for me here - *npm*, owned by GitHub, banned TOTP. GitHub, as far as I can tell, didn't. (It's still available in the UI and the docs have no warnings telling you not to use it.) So I suppose I can conclude that TOTP is insecure when you use it for npm and not when you use it for GitHub, according to Microsoft. https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/about-two-factor-authentication
About two-factor authentication - GitHub Docs

Two-factor authentication (2FA) is an extra layer of security used when logging into websites or apps. With 2FA, you have to log in with your username and password and provide another form of authentication that only you know or have access to.

GitHub Docs
@misty *rubbing eyes* wait. whaaaaaaaaaat
@misty @mcc did they lose control of the server-side of the TOTP shared secrets or something, forcing them to invalidate everyone's token and start over?
@raven667 @misty if i remember correctly there was a major phishing-related supply chain attack on NPM, bad enough to embarrass the entirety of Microsoft even though it wasn't their packages, about a week before, and I remember at the time wondering if that was Why
@mcc @raven667 Given the timing I'm fairly sure that's why, yes. I can understand why npm was scrambling but it's very strange seeing the completely different security policies between npm and GitHub despite being under one umbrella.
@mcc @leo @q There is already an open source passkey implementation. https://github.com/google/OpenSK it uses CTAP (the FIDO alliance standard "Client to Authenticator Protocol". It is implemented as a separate hardware device, but there's no reason a virtual USB HID device could not do the same.
GitHub - google/OpenSK: OpenSK is an open-source implementation for security keys written in Rust that supports both FIDO U2F and FIDO2 standards.

OpenSK is an open-source implementation for security keys written in Rust that supports both FIDO U2F and FIDO2 standards. - google/OpenSK

GitHub
@mcc @leo @q FIDO Attestation is *not* a web of trust. It is centrally managed by the FIDO alliance. There is no agreed-upon method for attestation for software passkeys, because there is nothing specifically to attest to: FIDO attestation is a mechanism to determine that a private key was generated on a specific piece of hardware and cannot be exported.
(Edit: Link to FIDO Metadata service, which is the source of truth for attestation roots: https://fidoalliance.org/metadata/ )
FIDO Metadata Service (MDS) Overview | FIDO Alliance

Explore FIDO Metadata Service (MDS), a centralized repository for relying parties to validate authenticator attestation and prove device model genuineness.

FIDO Alliance
@leo @mcc Apple refuses to attest their passkeys, so everyone else won’t implement an attention requirement as long as that stands
@q @leo @mcc that is fascinating. The first time I really sat down and learnt about passkeys was Apple’s WWDC talk on it, and they were glowing about the benefits of attestation. I wonder if they figured it was a fingerprinting risk that outweighed the mitm risk?
@leo @mcc @leon was that in the context of enterprise stuff? attestation very much has its uses there
@q @leo @mcc no they were really pushing attestation as a defense against wallets that would allow circumventing the time of flight check or other wallet-side behaviors like malware wallets with backdoors (when discovered)
@mcc @leo @q yes, for the record, we agree and are highly concerned about it
@ireneista @mcc @q i think the "solution" here is that apple doesn't have the market share to try locking people into icloud passwords (via this specific method, at least) but they do have the market share to stop google and microsoft from trying to lock people into their solutions
@mcc @leo @ireneista insert thanos perfectly balanced meme here
@mcc the primary point of attestation is so that enterprises can lock internal apps to the security keys they provide, at some browsers display a scary warning if the site requests it

@leo @mcc I believe Bitwarden does have an aaguid in the FIDO MDS: https://passkeydeveloper.github.io/passkey-authenticator-aaguids/explorer/

(I didn't actually download the blob to check though) so it does theoretically support attestation.

Passkeys Authenticator AAGUID Explorer

View the passkeys authenticator AAGUID community repository

@leo @mcc But yeah, I don't think I've ever seen anyone actually enforce attestation.
@cthos @mcc if i'm reading the code correctly it just generates a random keypair that doesn't chain to anything
@cthos @mcc ....which i guess technically counts as "implementing attestation" but not in any real meaningful sense

@leo @mcc Yeah, I've been rooting around in the client code on the hunch that it's doing the attestation signing on the server component, but all I can see is it sending a "none" assertion (but still hard-coding their aaguid)

They probably do have some code doing this for their enterprise customers.

@leo @mcc Oh so this is why Revolut and WhatsApp reject Bitwarden.
@fruitchypear no that's likely for a worse reason, apple doesn't implement attestation either

@mcc KeepassXC has been just flat out ignoring these mandates and doing their own thing with their passkey implementation and it worked for me with one local library's app that only supports passkeys, at least.

No idea how much it'll end up like running an obscure web browser and having every single cloudflare challenge fail, though. -_-

@mcc I cannot emphasize how much I am annoyed that KeepassXC turned out to be a milkshake duck.
@gourd I'm really frustrated.
@gourd I'd consider forking it and maintaining a noAI version myself, but the thing is, the UI is also pretty bad

@mcc (personally likes the UI)

stops and thinks about their own taste in UI relative to everyone else they know

Oh that is damning, isn't it. 

@gourd @mcc wait what happened to keepassxc?
@zrb @mcc They started using "AI" generated code.

@gourd @mcc oof

So many cool projects that seem interesting, and then I look into their source and see "CLAUDE.md" or some bullshit. I had to unboost a post recently because of that

@mcc I am not up to date with FIDO2, but I suspect that the spec allows services that accept passkeys to decide whether to care about passkey's provenance. I don't know how many do care. For U2F (the previous standard) caring about provenance was IIRC very rare.
@mcc not sure about software impls but a non-certified hardware device will still work with most websites. Websites can reject non-certified passkeys but that's their, opt-in choice, and pretty much only some banks or gov services do that. Source: I work on an open source FIDO hardware token.
@sgued open source hardware token is of intellectual interest to me…! like what does it run on? can i run it on an fpga or whatever if i have one?
@mcc We sell them at nitrokey.com. PCB design and firmware are open source so you could build your own, but they're still designed to be factory produced rather than DIY. During provisioning we set the attestation certificate in it so that's how we can be certified. The firmware must be signed so if you want a custom version you need a "hacker" variant that is not certified, but also less secure because not protected against evil maid attacks changing the firmware.
@mcc nobody cares about attestation, nobody ever will, it's a bugbear of webauthn that people keep bringing up