4 ms·

Passkey marketing is lying to you (it's actually really simple)

26 points by coldpie 2y ago

deleted 2y ago
[deleted]
josephcsible 2y ago
> 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.
- toomuchtodo 2y ago
  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.
  - josephcsible 2y ago
    How is that "identity assurance"? All attestation proves is, e.g., that the passkey is stored on an iPhone, not that it's stored on your iPhone.
    - deleted 2y ago
      [deleted]
    - deleted 2y ago
      [deleted]
    - toomuchtodo 2y ago
      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.
  - coldpie 2y ago
    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?
    - toomuchtodo 2y ago
      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.
      - coldpie 2y ago
        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.
        toomuchtodo 2y ago
        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.
        coldpie 2y ago
        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?
        toomuchtodo 2y ago
        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://www.bleepingcomputer.com/news/security/amazon-says-175-million-customers-now-use-passkeys-to-log-in/ 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-passkeys-update-april-2024/ 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/convincing-a-billion-users-to-love-passkeys-ux-design-insights-from-microsoft-to-boost-adoption-and-security/ 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/ https://state-of-passkeys.io/
- coldpie 2y ago
  Oof, I found a whole ton of anti-open-source-software quotes on the related Github issue https://github.com/keepassxreboot/keepassxc/issues/10406 https://github.com/keepassxreboot/keepassxc/issues/10406 : > 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.
  - lapcat 2y ago
    > I'm going to update the blog post, or maybe even delete it. Please don't delete the blog post! I think it's important for us to have these conversations.
    - coldpie 2y ago
      OK. I updated it instead.
      - Arnt 2y ago
        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.
- sowbug 2y ago
  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.
nabla9 2y ago
>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.
lapcat 2y ago
> 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.
vayup 2y ago
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.
- zamadatix 2y ago
  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.
- coldpie 2y ago
  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.

26 points by coldpie 2y ago

deleted 2y ago

[deleted]

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

toomuchtodo 2y ago
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.
- josephcsible 2y ago
  How is that "identity assurance"? All attestation proves is, e.g., that the passkey is stored on an iPhone, not that it's stored on your iPhone.
  - deleted 2y ago
    [deleted]
  - deleted 2y ago
    [deleted]
  - toomuchtodo 2y ago
    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.
- coldpie 2y ago
  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?
  - toomuchtodo 2y ago
    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.
    - coldpie 2y ago
      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.
      - toomuchtodo 2y ago
        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.
        coldpie 2y ago
        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?
        toomuchtodo 2y ago
        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://www.bleepingcomputer.com/news/security/amazon-says-175-million-customers-now-use-passkeys-to-log-in/ 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-passkeys-update-april-2024/ 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/convincing-a-billion-users-to-love-passkeys-ux-design-insights-from-microsoft-to-boost-adoption-and-security/ 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/ https://state-of-passkeys.io/
coldpie 2y ago
Oof, I found a whole ton of anti-open-source-software quotes on the related Github issue https://github.com/keepassxreboot/keepassxc/issues/10406 https://github.com/keepassxreboot/keepassxc/issues/10406 : > 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.
- lapcat 2y ago
  > I'm going to update the blog post, or maybe even delete it. Please don't delete the blog post! I think it's important for us to have these conversations.
  - coldpie 2y ago
    OK. I updated it instead.
    - Arnt 2y ago
      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.
sowbug 2y ago
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.

nabla9 2y ago

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

lapcat 2y ago

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

vayup 2y ago

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.

zamadatix 2y ago
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.
coldpie 2y ago
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.