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

    • Ferk@lemmy.ml
      link
      fedilink
      arrow-up
      1
      ·
      edit-2
      10 hours ago

      A good start would be to not bundle into the protocol a method explicitly intended for services to be able to securely identify what local software (or hardware) you used with the explicit purpose of allowing the service to be able to reject access if that client software (or hardware) is not allowlisted.

      Passkeys is a great idea. But the “Attestation” part of the protocol …not so much.

      • im_fine_sandy@nord.pub
        link
        fedilink
        English
        arrow-up
        1
        ·
        9 hours ago

        Is this with the intention of excluding bots?

        This has nothing to do with what we’re talking about.

        • Ferk@lemmy.ml
          link
          fedilink
          arrow-up
          1
          ·
          edit-2
          8 hours ago

          It may make it somewhat harder, but I wouldn’t say it makes bots impossible (eg. device farms).

          But I agree botting has nothing to do with what we are talking about.

          We are talking about “capturing” the user and I’m saying the protocol has built-in a method for services to require the users to use only the authentication methods the service allows.

          The attestation certificate includes metadata securely identifying the exact maker, model, and capabilities of the local authenticator you used, with the purpose of allowing services to verify if they trust the authenticator.

          So if you use your own no-name open source fork of a particular authenticator and don’t even register it with the FIDO Alliance Metadata Service then services requiring attestation would reject your keys (unless they explicitly make the exception for your particular AAGUID… but at that point why ask for attestation in the first place?).