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

@mcc the last time this came up people got really ominous at KeepassXC (yeah, I know) about sites rejecting "non-conforming implementations"

which means we end up at user agent spoofing for login 

@mcc I haven't adopted passkeys solely because I can't guarantee I won't need the damn things on a device that doesn't support them.

And up until recently KeepassXC + KeepassDX was my solution to that that almost made it workable but well... gestures at KeepassXC going in on fist-fighting people on Mastodon for AI

@gourd @mcc wow passkeys are sounding better and better

@gourd @mcc In practice that was one Okta employee being quite over-eager.

Attestation for WebAuthn credentials is dead outside of enterprise and maybe banking (but i’m in that industry, in the geography with the strongest legal requirements around transaction authentication, and I just don’t see it) use cases involving hardware-backed tokens

@mcc your conclusion is correct, you should just not use it for now
@ireneista Dunno where "for now" comes in, tho. It's not that this is a missing feature, it's that the feature I want is something the FIDO alliance has done extensive work to prevent being possible, and will one assumes work to prevent being possible in the future as well.
@mcc until something fundamental changes about either the industry or your requirements
@mcc sometimes when we're patient enough we can just out-wait bad ideas
@mcc …Time for a USB Bluetooth dongle?

@erincandescent How exactly does a Bluetooth dongle solve “I don't want to enable Bluetooth on my phone”?

@mcc

@krans @erincandescent

Erin, "Time for a bluetooth dongle?", timestamp: 06:21 PM

Andi, "I don't want to enable Bluetooth on my Phone", timestamp: 06:24 PM

I reckon she lacks precognition

@mcc Oops! That's not the order in which those messages were presented to me by my client.

@erincandescent: I apologize

@mcc would a USB Bluetooth dongle do the job? they're very very cheap these days.

(EDIT: ah, ok, yeah, other requirements posted after rather scuppers this idea)

@gsuberland @mcc Was about to suggest the same, and there were already two other suggestions :)