- cross-posted to:
- linux@lemmy.ml
37
- cross-posted to:
- linux@lemmy.ml
Ricky Mondello (@rmondello@hachyderm.io)
hachyderm.ioIf you actually read the “Passkeys are a trap. Do not use them.” post going around, you’ll find a transparent attempt to clumsily string together a conspiracy.
The post is predicated on the idea that a feature of WebAuthn called “attestation”, which is only used in high-assurance and usually corporate scenarios, and usually with physical hardware security keys, will be leveraged to hurt people, somehow.
The post posits that a website like X will bait and switch users: first, you get a passkey. Then, later, scary “attested” passkeys! This simply isn’t possible to do because attestation isn’t supported on the web for mass market, consumer authentication.
Attestation for passkeys (software-based, syncable credentials) is antithetical to their mass market goals, and would freeze out independent, non-corporate-backed credential managers. It’s an explicit non-goal of the designers of passkeys, who work together in a forum anyone can join.
And trust me, websites and apps like banks repeatedly asked for attestation at the beginning of the industry’s passkey journey. The platforms, browsers, and credential management apps have held firm that the goal of passkeys is reducing phishing and **not** some kind of trusted computing scheme. (And I will note: over my dead body!)
Besides the theory of the case being fundamentally wrong, there are several things that make the post disqualifying in terms of arguing something useful or important in the realm of security, privacy, and user authentication:
1. Intentionally presenting things that are complicated as inherently suspicious. (Delivering security by design can be complicated, yes!)
2. Describing TOTP as a “great solution” for adding security to a password-based account. When the most common threat model on the web is phishing (a word the post never mentions!), TOTP hardly buys you _anything_. TOTP is phishable.
3. Seeming to be unbothered by how many logical leaps are being taken without actually understanding the topic being discussed.
There are bad things happening in tech and untrustworthy people and companies do exist, but they’re largely in the AI space, not the “let’s stop people we love from getting compromised through phishing” space.
A rebuttal to an anti-passkey, pro-TOTP post that has made the rounds on Lemmy as well.


yes it is
So we shouldn’t have created HTTP because Google might appear?
Imagine if HTTP explicitly documented as part of the standard that the “User-Agent” header, when provided, must include a tamper-proof cryptographic signature that allows to securely identify which browser version the user has (with a consortium maintaining a list of registered browsers) so that websites can reject access if you are not using a browser they trust or they don’t like that your browser is too old…
Considering how much abuse there has been with the User-Agent header… I can’t imagine it being a good idea to include such a thing in the standard.
If on creation HTTP had included things like that, then I think Gopher and other competitors at the time might not have been a bad option, honestly.
I don’t see your point I’m sorry. This would make it easier for Google to exclude small competitors.
The point is that not all protocols are created equal. So “we shouldn’t have created HTTP” depends on what HTTP is specifying.
If a protocol makes it easier for big players to abuse the system, then it’s a worse protocol in that respect.
The point being made against passkeys is that, in some respects, it’s worse because of the inclusion of attestation as part of the standard.
we should have learned our lesson after they did and done our damndest to create protocols immune to capture. there were excuses in 1989, there aren’t now
How do you create protocols immune to capture?
A good start would be to not bundle into the protocol a method explicitly intended for services to be able to securely identify what local software (or hardware) you used with the explicit purpose of allowing the service to be able to reject access if that client software (or hardware) is not allowlisted.
Passkeys is a great idea. But the “Attestation” part of the protocol …not so much.
Is this with the intention of excluding bots?
This has nothing to do with what we’re talking about.
It may make it somewhat harder, but I wouldn’t say it makes bots impossible (eg. device farms).
But I agree botting has nothing to do with what we are talking about.
We are talking about “capturing” the user and I’m saying the protocol has built-in a method for services to require the users to use only the authentication methods the service allows.
The attestation certificate includes metadata securely identifying the exact maker, model, and capabilities of the local authenticator you used, with the purpose of allowing services to verify if they trust the authenticator.
So if you use your own no-name open source fork of a particular authenticator and don’t even register it with the FIDO Alliance Metadata Service then services requiring attestation would reject your keys (unless they explicitly make the exception for your particular AAGUID… but at that point why ask for attestation in the first place?).
You have a very strange way of communicating but I see your point.
Is this the new “killing baby Hitler”?
Honestly not sure what’s going on in this thread.
Don’t invent the internet because then you will have internet companies.