Passkey marketing is lying to you (it's actually really simple)
smokingonabike.com
smokingonabike.com
There's the rub. Unfortunately, KeePassXC doesn't have a Safari extension, for example, and I don't want to use iCloud Keychain. All I ever wanted was this:
> if you’re willing to manage your private keys manually by copying your keystore around, then there’s no need to use the Big Tech Cloud Service Magic stuff.
I can currently accomplish this with passwords but not with passkeys.
I predict that commenters are going to say, "you shouldn't use Apple devices then, duh", but you can't just look at the downsides in isolation without also looking at the many upsides of Apple tech, at least for me. There are always tradeoffs, no perfect technology, especially in a duopolistic market.
A relying party is basically just "the website that you're trying to log in to".
> but this statement really puts the Passkey spec authors in a bad light. It should not be possible to block me from logging into a service because they don’t like the password manager I use. Between the fact that the spec author sees this capability as a good thing and the Big Tech-focused marketing, this really makes me think that the Passkey spec authors do not have users’ best interests in mind. They clearly think using this technology to lock users into Big Tech ecosystems is a feature, and other uses are an annoyance that they have to grudgingly support.
Indeed. That (anti)feature is called attestation, and it really does exist for the sole purpose of letting websites lock users into Big Tech ecosystems.
As long as you can always create a new passkey on a new device (through some identity proofing or assurance process), the risk is minimal that you're locked into an ecosystem.
I'd say contact the FTC about this, but I'm unsure how helpful they will be for the next four years.
Blog postings stating "Passkeys bad" is the limit of influence available. The rest of the global user population is going to rapidly adopt through whatever onboarding flows web properties put in front of them to upgrade their creds from passwords to passkeys. I suppose my question back would be "What do you think as an individual you believe you can do about the situation you believe is suboptimal?"
https://www.bleepingcomputer.com/news/security/amazon-says-1... ("Amazon says 175 million customers now use passkeys to log in")
https://blog.google/technology/safety-security/google-passke... ("In 2022, for World Password Day, we launched passkeys. Today, we’re proud to announce that they have since been used to authenticate users more than 1 billion times across over 400 million Google Accounts.")
https://www.microsoft.com/en-us/security/blog/2024/12/12/con... ("Convincing a billion users to love passkeys: UX design insights from Microsoft to boost adoption and security")
> On the record, I do support whatever mechanisms can be implemented via standards to prevent vendor and platform lock in.
It seems like removing the attestation feature from the spec would get us there.
> Blog postings stating "Passkeys bad" is the limit of influence available.
Yeah. I'm no one special, but I wonder if blog posts from places like the EFF and SFC could get some publicity on the (apparent) fact that Passkeys are an anti-user-freedom technology, just like DRM and TPM are.
[1] https://www.wyden.senate.gov/
[2] https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
> When required, the authenticator must perform user verification (PIN, biometric, or some other unlock mechanism). If this is not possible, the authenticator should not handle the request.
> [A passkey provider certification process] is currently being defined and is almost complete.
> This implementation is not spec compliant and has the potential to be blocked by relying parties.
> Then you should require its use when passkeys are enabled ... [You may be blocked because] you have a passkey provider that is known to not be spec compliant.
> I suspect we'll see [biometrics] required by regulation in some geo-regions.
> I see a lot of misinformation and incorrect guesses about the intentions of various parties in the recent threads. If it would be helpful, I'm willing to have a [private, non-public] call with interested parties to try and answer some of the questions that have been raised to ensure we have a common technical understanding of FIDO/WebAuthn.
I felt reasonably positive about Passkeys while writing this blog post, but continuing to read the spec authors' insistence that only Big Tech may handle these problems is extremely worrying. I really want to like this feature, but the authors are acting like complete jerks and driving me away.
I'm going to update the blog post, or maybe even delete it. Attestation is a complete deal-killer for this tech.
Please don't delete the blog post! I think it's important for us to have these conversations.
Open source isn't about making it easy to perform social engineering.
The FIDO spec for security keys supports attestation as well. It makes sense; an enterprise might want to limit employee authentication to specific hardware that it has vetted, or another company might have determined that the supply chain for a specific brand or model of security key wasn't hardened enough for their threat model.
You, as an individual, might not want the relying party to be able to use this information when deciding whether to authenticate you. But authentication is a dialogue, not a monologue.
Attestation might allow the lock-in you fear, but that's absolutely not its primary purpose.
>Ignore all the lock screen and biometric stuff that the marketing is screaming at you. You can generate Passkeys on your computer just like we’ve been doing with SSH keypairs for decades. You can store those keys however you like, so long as you have a way to feed them into your web browser to provide to the service at login-time. You can copy your Passkeys around as much as you like, to any device you like. You can share them with friends.