• brackled@lemmy.world
    link
    fedilink
    arrow-up
    12
    ·
    12 hours ago

    My background is very much not in this world so caveat my questions/response below with that mind set. I do however try to practice decent personal opsec such 2fa (TOTP), password manager with random generation, etc.

    I feel like a lot of what you stated was covered in the article. For example the article states that problem isn’t the number of stakeholders, it’s that none of them are consumer advocacy groups.

    I understand that the author maybe leaned on the password sharing example too much but I think that was in an effort to present the material in a friendlier manner to the average reader. The closing statement makes it clear it’s not really about Netflix, etc. The main concern is that attested passkey requirement will now be the easiest way to force specific software and hardware upon user. The GraphenOS example is a good one.

    You might not use the attested flag in that manner but I have zero doubt that once passkey adoption rate passes a certain threshold Google will be more than glad to miss-use that flag to lock people out of their gmail account unless they have the most recent phone and software.

    Do you have any examples of any public service requiring attested keys? No, because it really doesn’t make sense. But because the protocol supports it, people shouldnt use passkeys? Shitty hot take.

    I think this is a bad take. “Because this potential is not being misused right now it won’t be a problem in the future” has not really served us well thus far.

    My understanding is that the article is saying that passkeys are giving away too much control to the second party. That can and will be abused.

    But again, layman’s understanding from my end.

    • Klox@lemmy.world
      link
      fedilink
      English
      arrow-up
      2
      arrow-down
      1
      ·
      edit-2
      5 hours ago

      Happy to discuss a few points you’ve brought up.

      it’s that none of them are consumer advocacy groups.

      I would put that more as a curiosity than a red flag. I doubt they were excluding groups, but happy to hear about if they were (e.g. donation minimums or something to that effect). The author actually says that whole paragraph is “notable” – great, noted. I hope that doesn’t mean they were using it as an argument for “Do not use [passkeys]” (the title of the article). FWIW, W3C recommends use of passkeys. EFF has had blog articles for 3+ years suggesting advantages of Passkeys. I also don’t know what a consumer advocacy group would suggest differently here – DONT implement an attestation spec? Attestation is a massive improvement for specific types of security.

      The GraphenOS example is a good one.

      I went and looked for what you were referring to and didn’t find anything. What do you mean by this? I use GrapheneOS. I use passkeys. Google being hostile to third party OS doesn’t seem related but maybe I am missing something.

      I have zero doubt that once passkey adoption rate passes a certain threshold Google will be more than glad to miss-use that flag to lock people out of their gmail account unless they have the most recent phone and software.

      Well this seems like a reasonable point I should expand on. Maybe I can plant a seed of doubt about this hypothesis. A few comments:

      1. People being locked out of their email is actually one of the biggest logistical nightmares for email providers. Proving someone is who they say they are is actually fairly difficult as well as doing it at scale. People lock themselves out of their own email. People get locked out of their email because of phishing attacks. In practice, Passkeys reduce phishing rates significantly. That’s a massive win for email providers in reducing their burden. Intentionally locking out a massive number of their customers is an unthinkably bad move, comically bad. It wouldn’t happen.

      2. Email is the most important mechanism of communication for people’s security. Bank and financial accounts, paid services, government notices… they are almost all through email. The idea that they will vendor-lock email to specific hardware… it’s not realistic. They would face such massive PR And public blowback. Email is also accessed from more than just your phone. “Requiring” an attested phone would kill a massive use case.

      3. People already feel locked to their email provider – it’s extremely difficult to change all contacts you have to a new email address. Passkeys don’t change that. Phone hardware doesn’t change that. So I’d say it’s just a continued problem, and not a reason to not use passkeys.

      4. The FIDO Alliance had like three phone manufacturers out of 250 members.

      Overall, I don’t see how passkeys, or attestation, could lead to a world where any public service would want to require attestation, and even if they did, there’s no reason it would be “requires my X branded phone”. These companies supported the development of this protocol for the specific reason of NOT wanting to cater to specific vendors. This is a vendor-neutral specification. There are many hardware and software providers. They all have their own motivations, and they hope implementing the spec brings in more customers, improves consumer security, and reduces their operational costs. Do you still have zero doubts about a future world with vendor-locked attested passkeys for public services?

      passkeys are giving away too much control to the second party.

      There are already dozens of hardware and software passkey vendors. It’s honestly amazing how little lock-in there is. There’s a half dozen FOSS authn services providing passkey services. You can buy dedicated hardware for passkeys from multiple independent companies. What “control” are you referring to? Companies could always force rotate your password, make it invalid, etc. Any control you thought you had was an illusion.

      Cheers