A rebuttal to an anti-passkey, pro-TOTP post that has made the rounds on Lemmy as well.

  • TrollAccount69@lemmy.ml
    link
    fedilink
    arrow-up
    8
    ·
    2 days ago

    You can, maybe, have you actually imported or exported all of your passkeys before?

    The concern is that in order to solve a technical problem, trusting the user, a system of actions and technologies called remote attestation was added to the passkey design. It allows for the service being authenticated into to figure out if it even wants to accept the supposed users attempt. One way remote attestation can be done is by client. Not using a client the service accepts? No way in even if you have the right credentials!

    This is really powerful technology that lets me ensure my own services won’t even allow connection to insecure clients or just clients I don’t wanna talk to.

    But of course we’re not talking about me using passkeys to gate access to my own services I control, we’re talking about Google, Microsoft and Apple doing it. So built into the passkey standard is the capacity for the service to simply stop allowing you to access it with a passkey if you don’t have the right thingy (or any other suite of remote attestation technologies, client is just one example).

    Do you know if your passkeys do this? Do you know how to get in to your accounts if passkeys are suddenly not working?

    People are mostly afraid of lock in, control, etc here but the real problem is that most users don’t understand how passkeys work. How can you comply with a regime of passkey use if you don’t know how they work?

    • usdeurpes@lemmy.zip
      link
      fedilink
      arrow-up
      1
      ·
      2 days ago

      Interesting. I was ignorant about that. For my use case (a faster alternative to totp but I still have that in case), it’s pretty useful, but I can definitely see the concerns now.