• Clay_pidgin@sh.itjust.works
    link
    fedilink
    arrow-up
    0
    ·
    9 hours ago

    What I don’t like about passkey implementations I have used on my phone is that is completely opaque who is generating the key and where it is stored. I have the Android and chrome password managers disabled, but I think Google is trying to store my passkeys, which I do not want. Bitwarden can create and store them, but I have the feeling Android is hijacking the enrollment.

    I’m also not clear on the benefit to me, since I already use a password manager with extremely long random passwords unique to each login.

    • Em Adespoton@lemmy.ca
      link
      fedilink
      arrow-up
      0
      ·
      8 hours ago

      I can’t say much about the hijacking side, other than that you have to be careful when you set them up.

      The advantage over passwords isn’t on your side of the equation; it’s everywhere else.

      With a password, the password or its hash has to be sent to some other party who then has to hold it in cleartext in memory to validate it. This means some other person or software can steal it and use it at their leisure. TOTP improves this by adding a second factor in the authentication chain… except that to make it work smoothly, a token is set that is almost as easy to steal as the password — it’s just got a shorter expiry.

      But with a passkey, once it is set up, every interaction uses a unique token based on the existing relationship— so sniffing part of a transaction is useless to decrypt it, agent in the middle will fail, and if either side is compromised, the new actor won’t be able to do anything with the secret without setting up a NEW passkey.

      So yeah; the risk with passkeys is that they’re opaque enough that someone could be tricked into establishing a new one with an untrustworthy party.