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