> I don’t know what a “relying party” is, so I’m not sure exactly what this threat entails
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.
Power users will always detest certain aspects of higher levels of digital identity assurance. Regardless, some use cases call for those assurances (that your passkey is you, especially as it relates to privileged actions).
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.
Identity risk detections and conditional access. The more you know during an authentication attempt, the more effectively you're able to manage risk. What and how much signal you seek is a function of your use case around identity and access management.
A website could use this feature to require that I only log in using (say) Google or Microsoft or Apple's implementations, right? Under those conditions, how could I log in using my Linux desktop?
That's true. A web property is under no legal or regulatory obligation to ensure you can login with your preferred method or endpoint configuration. This does not apply only to passkeys of course, the web property can always dictate CIAM terms to users.
I'd say contact the FTC about this, but I'm unsure how helpful they will be for the next four years.
Okay, but I don't have that problem with passwords. So passwords have an enormous advantage over Passkeys, in that they don't allow the service to dictate what I can do with my own data.
Also true, but that's an advantage to you as a byproduct inherent of the primitive, whereas it is a huge disadvantage to enterprises to have to defend against credential spraying and other forms of attack against simple auth factors such as email/username and password string.
Are you willing to sacrifice the entire concept of open source software to gain that? You're really OK requiring everyone on the planet to use exactly three proprietary software vendors' software stacks?
Am I willing? I personally have no control over the situation at scale as it relates to the rapid uptake in passkeys across major web properties. There is no legal or regulatory mechanism to prevent passkey adoption, and Linux users are so small of a customer population in most circumstances that the loss of them as customers or users is immaterial. On the record, I do support whatever mechanisms can be implemented via standards to prevent vendor and platform lock in. Platform and vendor lock in is bad, I do not disagree with you about that point.
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://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.")
Yeah I'm trying to understand the landscape myself. Until I learned about attestation, it seemed like a cool tech and I even spent all morning writing this positive blog post about it. I was really disappointed/hurt to read the spec authors openly not caring about user rights.
> 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.
If this is important to you, I would reach out to Senator Wyden's office on the topic [1]. He is a known good advocate of sensible technology policy [2]. Companies do not fear complaints, they fear statute and regulatory requirements. Genuinely wishing you success in your policy advocacy journey on this topic. Pretend you're a lobbyist; you're lobbying for computational freedom gratis. Cory Doctorow might have some helpful advice for you too, his contact info is easy to find.
Yeah, thanks. I think most likely I'd start by emailing the spec authors in question, since there's a decent chance you & I are misunderstanding something. Maybe a small tweak (like "services shouldn't reject clients without a really, really good reason, like you're authenticating guards at Fort Knox type stuff") would be sufficient to make this a non-issue.
> 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.
Pay close attention to this sentence: "Let determined people do that, but don't make it easy for a user to be tricked into handing over all of their credentials in clear text."
Open source isn't about making it easy to perform social engineering.
That (anti)feature is called attestation, and it really does exist for the sole purpose of letting websites lock users into Big Tech ecosystems.
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.
>Passkeys are a public/private keypair authentication system. That’s it.
>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.
> 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.
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.
The premise that this is a new drawback introduced by passkeys is false. If a relying party wants to lock you into big tech ecosystem for authentication, they can do that today by only supporting SSO from them. They don't need to wait until passkeys come about.
The relying party usually doesn't care about big tech, they just want to put the easiest method in front of the user. Passkeys mays don't need to be the original invention of lock in to be used in a way as to cause more of it.
The people behind SSO efforts or whatever aren't going around to open source projects and threatening them with their users being blocked if they don't implement anti-user features. The people behind Passkeys are doing that. It's a really bad look.
27 comments
[ 7.0 ms ] story [ 123 ms ] threadA 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")
https://state-of-passkeys.io/
> 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.
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.