You must log in or # to comment.
The passkeys most people use are synced passkeys, stored in iCloud Keychain, Google Password Manager, 1Password, Bitwarden or whatever other software of your choosing. These passkeys don’t give websites an attestation statement at all, and though a site can ask, what comes back is none.
This changes with… ~1 AI prompt by each of the password managers.
And if someone as big as Google tomorrow says “for ‘security reasons’, in 3 months we allow passkeys only from the apps that provide attestation” (and they 100% will do that at some point, there’s not even 0.0001% chance that they won’t do it as soon as the timing will be favourable for them), then all of these above will implement attestation statement the very next week.
If a consumer website decided tomorrow that it would only accept attested passkeys, it would lock out almost all of its own users, instantly. What website is going to do that?
Google. They don’t give a fuck. Because they have an enormous leverage to make all major password managers comply the very next week.
And then, after Google, once support is there, everyone else.
Besides, the guidance for consumer sites has been to not even request attestation for years now.
Nobody cares. Vendorlocking you is in their interest (their = mostly bigtech ofc, not fediverse, obv), so they’ll do it.
Attestation Isn’t What You Think It Is
The post describes attestation as proving “that an approved passkey manager, operating system, and firmware are in use” which is simply not true.
When it is present, WebAuthn attestation tells the site the make and model of the authenticator, identified by its AAGUID, with a certificate chain from the vendor to back it up. It says nothing about your OS, your browser, your extensions, whether your phone is rooted or jailbroken, your firmware version, or even what colour it is.
This whole section is outright wrong. The very idea behind attestation is to bind the key pair to the hardware device through a chain of trust. See https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API/Attestation_and_Assertion for how it actually works.
Summing up, remote attestation is a horrible anti-consumer piece of crap, the main purpose of which (in the context of bigtech) is to vendorlock the users to a few very specific hardware-software stacks fully under control of a very few companies.
The only things that stands between bigtech and fully vendorlocking you are passkeys adoption and the share of non-bigtech-controlled devices + OSes + password managers.
Given that “normies” don’t give a flying fuck about using privacy-respecting tech stacks which results in 99% adoption of Apple/Google/Microsoft triopoly, it, unfortunately, reduces the defence against such vendorlocking to passkeys adoption only ¯\_(ツ)_/¯
This is a very slippery slope kind of argument and you’re arguing with people working on Passkeys who likely know how they work.
If you’re a fan of conspiracy theories consider this comment from the discussion linked above:
Let’s just put out a counter conspiracy theory here. There are people who benefit from phishing. There’s a whole crime-as-a-service industry out there. So who would benefit from spreading FUD about passkeys? Qui bono? Exactly!
It doesn’t matter who claims what and who spreads what.
What matters is who controls what, and what they are doing already now with the things they control.
Currently the whole market of mobile OSes (~100%) is controlled by two companies: Apple and Google.
The whole market of desktop OSes (~95% or something like that?) is controlled by three companies: Apple, Google and Microsoft.
Two of them (Apple and Google) already use remote attestation to harm even potential competition and vendorlock consumers to their OSes — Apple through Apple’s App Attest API and Google through Play Integrity API.
They already extend this even to desktops which they don’t yet fully control (Apple natively, Google through their captcha service): https://grapheneos.social/@GrapheneOS/116550899908879585
The apps already ban non-ceritified devices: https://grapheneos.org/articles/attestation-compatibility-guide#apps-banning-grapheneos
Specifically, one of the authenticators — Authy — already bans non-certified devices.
The example is GrapheneOS, because they track and collect and explain this information, but every non-bigtech-governed OS is under threat: all Linux distros, all *BSDs, all mobile Linux distros running Android emulators, LineageOS, Custom ROMs etc.
Now the question: will Apple and Google (and Microsoft and all their other accomplices) not [ab]use passkeys to do exactly the same using yet another piece of technology?
No?
MUAHAHAHAHAHAHAHAHAHAHAHAHA! Naïve child!
Of-fucking-course they will! Gladly, and as soon as they can. You can call this conspiracy, blah-blah-blah, but it’s fucking happening. Already. Just with the different piece of technology. But with the same eternal “yOuR sEcUrItY iS iMpOrTaNt FoR uS” excuse.
Passkeys — WebAuthn — is an amazing technology. Brilliant.
But with one fucking huge problem: a backdoor that 100% will be abused by these assholes.
Now the questions is: is the security that this truly amazing tech (no sarcasm!) brings worth giving up the [already almost taken from you] control over your digital life?
Who’s using remote attestation for Passkeys? You’re conflating requirements for app signing on Android with an encryption scheme.
I’m not interested in slippery slope arguments, people who use this argument end up arguing against LGBT marriage (they’ll marry dogs next!). Will you? Slippery slope logic says yes.
Who’s using remote attestation for Passkeys?
Microsoft, for example.
You’re conflating requirements for app signing on Android with an encryption scheme.
I’m not conflating anything.
Encryption scheme has nothing to do with remote attestation. Passkeys, being not an encryption scheme, but an authentication framework, does, by having it as one of its features.
App signing on Android has nothing to do with the remote attestation. Google Play Integrity Protection, being not an app signing mechanism, but an actual remote attestation mechanism, does.
Both Passkeys framework and Play Integrity Protection can be (and the latter already is) used for market monopolization and consumer vendorlocking.
I’m not interested in slippery slope arguments
You’re free to fuck off far into the distance then.
people who use this argument end up arguing against LGBT marriage (they’ll marry dogs next!). Will you? Slippery slope logic says yes.
And even more so with this kind of offensive and provocative narratives.
Did you even bother to read that first link? It’s just a description of how Passkeys work. Why are you sending me irrelevant garbage like this and wasting my time? Get off that LLM or whatever you’re on, I’m not reading further anything your write. I’m blocking you, goodbye.
And criminals would also want to spread “FUD” about Flock Surveillance and other beacons of Safety and Security, those damned scoundrels
Arguments against Flock and how it’s used specifically are based on reality, not the slippery slope. Flock-like solutions are deployed in many places (and even mandated by EU) without much outrage. Automated car surveillance is a good thing in general and segmental speed measurement is great at increasing road safety.
I couldn’t disagree more. A surveillance state is bad, no matter which authoritarian or collective of authoritarians holds the reins.
“For our security” and “for the children” are the two excuses fascists use to excuse destruction of privacy and human rights in general
I mean, we already have it. Wherever it’s rolled out drivers start to behave which measurably saves lives.
I personally hate how passkeys have been implemented, how they frequently break for me making them an unreliable 2FA, and how they are being crammed down my throat.
Also, if the passkey is being synchronized between devices it is functionally useless as a 2FA method in the first place. In order for something to be two factor authentication it needs to be a different type than the primary factor. The primary factor is something I know and the secondary factor is supposed to be something that only I have. As soon as I can just log in to a password manager to get the thing on any device it’s no longer a thing that only I have; it’s as useful as just having two passwords and requiring both.
At least with TOTP codes I can choose which ones go in the password manager and which ones go in a dedicated app that is not synchronized. You can’t do that on Android with passkeys because you have to pick one provider for all the passkeys on your Android device. If I want every service to use pass keys and the majority of those services do not need the additional security then I would pick my password manager as the storage. Then for more secure services it’s a nuisance to change the system setting from my password manager to the built-in system implementation so that I can get to the more secure passkey. Whereas with my TOTP codes I just open the password manager and see it’s not there and then open the TOTP code app and copy it from there. The alternative of course is I pick the more secure option for every service even ones that I don’t care about at all and then it’s just an additional nuisance to fix it when my device breaks.But I do recognize being able to be tricked into entering a 2FA code into the wrong area is a problem.
I wonder if the implementation impressions are dependent on the platform. I’m using Apple devices for my phone and laptop, also Apple Passwords and Safari. Whenever I see Passkeys prompts it’s very seamless and almost the same as if I was filling in a password. It’s very confusing to read what people write about it online, I can only imagine people hurting themselves on purpose dramatically like in an old teleshopping ad. That said, there’s maybe 5 websites I frequent that do Passkeys and I never decline creating one so the adoption isn’t going great.
It’s very dependent on RP ime. Most (90%+) are really easy to work with and “it just works”. But sometimes I go to use my passkey and it wants a hardware key when I saved my key onto my password manager and so I can’t actually respond to the request for the passkey at all. It’s not super common but it does happen.
Firefox/Windows/ProtonPass
