So here's what stops me from using Passkeys.

[mcc@mastodon.social]

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.

[mcc@mastodon.social]

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".

[mcc@mastodon.social]

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.

[gourd@indiepocalypse.social]

@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

[leon@peoplemaking.games]

@mcc 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.

[mcc@mastodon.social]

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?

[leo@60228.dev]

@mcc attestation is optional and bitwarden afaik doesn't implement it anyway

[mcc@mastodon.social]

@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.

[leo@60228.dev]

@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

[leszek_karlik@circumstances.run]

@mcc

I sometimes wonder if I want passkeys, but as far as I understand, they provide convenience at cost of security.

A proper random password kept in a password manager combined with U2F/TOTP on a separate device is more secure, because you have two independent factors for login (and the password manager and U2F provide the anti-phishing so beloved by FIDO alliance).

With passkey, you really have one - the password manager with the passkey.

But it is more convenient than using a password manager and an U2F token.

[smartasabrick@techhub.social]

@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.

[mcc@mastodon.social]

@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@mastodon.social]

@Leszek_Karlik A password is less safe than a passkey because it can be MITMed and reused. On entry it can be stolen if your computer is compromised or there's a camera watching you type. On receipt, it can be exfiltrated if the web server or its edge server is compromised.

Now, random PW+TOTP as you say, that looks more appealing the more I see how passkeys turned out. But with passkeys in the world TOTP support may not be an option in future (GitHub recently put hard restrictions on TOTP use)

[mcc@mastodon.social]

@Leszek_Karlik There was a period of some *years* that Twitter was, due to a "mistake"¹, logging every password as it came in from the login page, to a plaintext log file no one² realized was there. This single incident to me proves we want negotiate-shared-secret, not password-transmit, login protocols.

https://blog.x.com/official/en_us/topics/company/2018/keeping-your-account-secure.html

¹ IMO the chances are exceedingly high the "mistake" was inserted on purpose by an employee working on behalf of a nation-state actor

² Except the nation state actor.

[hyc@mastodon.social]

@mcc we've had perfectly good solutions for this for ages. Kerberos tickets and client X.509 certs work great when you have a centralized authentication authority. SCRAM works great for one-off individual sites. https://en.wikipedia.org/wiki/Salted_Challenge_Response_Authentication_Mechanism

There's no reason for anyone to be sending passwords over the wire any more, but also these all still work without eliminating passwords completely.

[ryanprior@mastodon.social]

@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?

[misty@digipres.club]

@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

[mcc@mastodon.social]

@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.

[ryanprior@mastodon.social]

@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.