Comment on Passkeys Explained: The End of Passwords

• asmoranomar@lemmy.world ⁨5⁩ ⁨days⁩ ago

  Keep in mind, still discussing the underlying fundamentals and not the user experience.

  MitM attacks are frequently covered in white hat hacking, often after an actual event takes place. It is considered a third party attack, and it does break trust. It is a security threat, and to claim it doesn’t count is absurd. I’ve seen a few reports personally from internal, but I’m not at liberty to speak specifics about them. On the topic of replay attacks, TOTP is vulnerable, but passkeys are not (yet, I’ve seen people try though). This isn’t the only type of MitM attack, and, again, both are somewhat vulnerable.

  TOTP is nothing, nowhere similar to passkeys in any way. You do NOT generate codes with passkeys. Passkeys are a form of public/private keys that are used to create a challenge/response request and used to generate a digital signature. The keys are not passwords (aka “shared secrets”). Digital signatures are also not passwords. The only other thing I can think you mean by “code generation” is that you’re using it as a generic catch-all, but that happens with…well everything (even passwords), depending on context.

  I don’t want to sound too much like a die hard passkey fan - and you are right - passkeys are extremely overkill if you use anything above a plain old password. In some cases, layered security can be just as effective. The problem is that most people do only use plain old passwords. If we can get any kind of extra security, even TOTP, then all the better. There are also some cases passkeys are not feasible, so it’s good to have alternatives.

  source

  • sugar_in_your_tea@sh.itjust.works ⁨5⁩ ⁨days⁩ ago

    It is a security threat, and to claim it doesn’t count is absurd.

    Oh, absolutely.

    Replay attack is the wrong term, here’s the threat model I’m talking about. Basically, the attacker watches the authentication flow and uses the resulting session (token?) to make web requests as you, stealing whatever data it wants. There’s no attack on the authentication scheme, but on the shortcuts web services use.

    It doesn’t matter if you use passwords, TOTP, or webauthn, there’s going to be some vector to attack the system without breaking the authentication mechanism.

    The average user isn’t going to see much security benefit from webauthn vs TOTP in the same way that adding a better lock to your front door is unlikely to improve your overall home security, because at a certain point, the burglar will just smash a window. TOTP is good enough because it’s safe from attacks on email and SMS that worse one-time code systems use. You should definitely have a lock on your door, but at a certain point, the lock is no longer the weak point in the system.

    And yes, I’m using “code generation” as a generic catchall. I group auth systems like so:

    • offline threats - e.g. passwords that can be broken by seeing the hash
    • reliant on third party service that can be attacked separately - email and SMS
    • "code generation" - uses some cryptographic mechanism to generate some unfakable code that can’t be reused; seeing more examples doesn’t help, and codes can’t be reused

    If your password manager handles the second factor, the user experience of TOTP vs webauthn is nearly identical, and the security is nearly identical to your average attacker, to the point where they won’t attack the authentication mechanism itself, but something else on the website or the password manager itself.

    The problem is that most people do only use plain old passwords. If we can get any kind of extra security, even TOTP, then all the better.

    Exactly. The difference between TOTP and webauthn only really matters if you’re a government or something else where state-level actors are part of your threat model. If your service uses one or the other, the distinction isn’t important to the average user.

    source