• NaN@lemmy.sdf.org
    link
    fedilink
    English
    arrow-up
    29
    ·
    1 year ago

    Someone on slashdot correctly pointed out that these are only single factor on the server end. You enter a pin to unlock the device, the server can check if the device says you unlocked it, but there is no sending a second factor to the server. If a device was hacked to get the keys, or just says to the server that you presented a pin but didn’t really, the server has no clue. Passkey + TOTP would be multi factor on the server side.

    • lemmyvore@feddit.nl
      link
      fedilink
      English
      arrow-up
      16
      ·
      edit-2
      1 year 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.

      • NaN@lemmy.sdf.org
        link
        fedilink
        English
        arrow-up
        2
        ·
        1 year ago

        I understand how it works, but again, it is not two factors being used to authenticate to the server.

        It is a single factor being used to access the vault. The server has no way of confirming this actually happened, the device just tells the server it has happened. A single factor is then used for authentication. This seems especially worth knowing since most cell phones deliberately weaken the security by sharing them between devices.

        Passkeys would preferably not be stored on the same device as a secondary factor used for authentication. Hardware tokens have supported them for years at this point, they can also hold TOTP keys instead.

        • 0xD@infosec.pub
          link
          fedilink
          arrow-up
          5
          ·
          1 year 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.

          • NaN@lemmy.sdf.org
            link
            fedilink
            English
            arrow-up
            2
            ·
            1 year ago

            If they compromise key material on your phone they still cannot get into whatever you are authenticating to, because it uses a completely separate factor that should not be on your phone.

            • ghterve@lemmy.world
              link
              fedilink
              arrow-up
              3
              ·
              1 year 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.

              • NaN@lemmy.sdf.org
                link
                fedilink
                English
                arrow-up
                3
                ·
                edit-2
                1 year ago

                You’re assuming that the passkey is on their phone and the phone is compromised. Passkeys can also be stored in password managers, or hardware tokens, or people’s iCloud or Google accounts. And if someone’s device is compromised, they have keys to everything even if the user never logs into those services to grab session data. If someone compromises my password vault they get passwords, but not TOTP keys. If they compromise my vault that is holding passkeys, that is all they need.

                I am only pointing out that a single factor is all that is sent to the sever, with most no longer allowing a secondary factor for authentication, and all of the security is all dependent on the client-side now.

                • Natanael@slrpnk.net
                  link
                  fedilink
                  arrow-up
                  2
                  ·
                  1 year 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

      • NaN@lemmy.sdf.org
        link
        fedilink
        English
        arrow-up
        2
        ·
        edit-2
        1 year ago

        The second factor doesn’t necessarily exist, since you’ve moved all of that to the client side now. It entirely depends on implementation and that the implementation is done correctly and is honest. The server only knows that you have the key, it’s single factor authentication.

        In the past, it verifies that I know the password and that I have a key on the server side through separate challenges.

        It’s still way better than username / password, it just has new (more difficult) vulnerabilities.

    • Natanael@slrpnk.net
      link
      fedilink
      arrow-up
      1
      ·
      1 year 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