4 ms·

> 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

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

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.