• lemmyvore@feddit.nl
      link
      fedilink
      English
      arrow-up
      16
      ·
      2 years ago

      TOTP generated on the same device as the passkey is not a secondary factor. It will have been compromised together with the passkey.

      For passkeys, the secondary factors are used to access the passkey vault, not auth to the server. And these secondary factors should be a master password, biometrics, or physical keys. TOTP and SMS are out.

        • 0xD@infosec.pub
          link
          fedilink
          arrow-up
          5
          ·
          2 years ago

          I’m not sure I follow you - if someone can compromise the key material on my phone that is protected by a different factor, then it doesn’t matter whether the 2FA is server-side or not, it’s compromised either way.

            • ghterve@lemmy.world
              link
              fedilink
              arrow-up
              3
              ·
              2 years ago

              It seems like you are trying to protect against a compromise of the user’s device. But if their device is compromised then their session is compromised after auth anyway and you aren’t solving much with extra auth factors.

                • Natanael@slrpnk.net
                  link
                  fedilink
                  arrow-up
                  2
                  ·
                  2 years ago

                  If the user can perform all steps on the same device then it doesn’t make sense to assume only specific set of keys will be disclosed, you have to assume everything on the device can be compromised

    • Passkeys are indeed only the first factor. A second factor could be a(n unrelated) password, or raw biometric data.

      The traditional authentication factors (something you know, something you have, something you are) still work like they used to. Passkeys use the “something you have” factor by default.

      The “something you are” factor (biometrics) isn’t commonly used, because most services actually use a stored secret that gets unlocked through biometric rather than biometrics data directly; any fingerprint login is just a public/private key in implementation, except the hardware is supposed to not use that key unless the biometrics sensor validates you.

      Theoretically you could achieve the same factor as passkeys by logging in through username + TOTP code, because TOTP codes are only supposed to be generated on a dedicated device you have.

      With some implementations of passkeys, the factor becomes a bit ambiguous. For example, a synchronised passkey behind just a password might as well be a password, albeit for a different service.

      For traditional passkey storage (a TPM, a Yubikey), this isn’t a problem of course.

    • Natanael@slrpnk.net
      link
      fedilink
      arrow-up
      1
      ·
      2 years ago

      Passkey plus TOTP doesn’t really make sense (they’re both client side cryptographic keys, you don’t need two protocols), at least use a PAKE algorithm with a PIN instead if you want the server to be able to check the user’s knowledge of a secret without sending it in a readable form