Comment on Passkeys Explained: The End of Passwords
sugar_in_your_tea@sh.itjust.works 5 days agoYeah, the implementation is very different.
I’m just saying that it’s similar from an average user point of view. You set it up once, then your app generates a unique code that the server can associate with you in a way that can’t be broken by a third party watching traffic.
asmoranomar@lemmy.world 5 days ago
That’s false, TOTP can and has been the target of man in the middle attacks, successfully. The implementation of passkeys makes man in middle attacks more difficult, but it could still happen. So both are susceptible to third parties to some degree.
As far as point of view, I was assuming we were talking about the process, since the goal of passkey UX is to be largely the ‘same as’. Which, to be frank, is way less dedicated since both the implementation of passwords and passkeys can vary widely (2fa, email, id, otp, etc). If we exclude those, the UX is the same - some users might be even using passkeys and not know it.
sugar_in_your_tea@sh.itjust.works 5 days ago
The only MITM attack I’ve seen is entering codes before the user does. That’s not breaking TOTP in any meaningful way (which is what I was trying to get at), so it would be similar for password entry or even passkeys if they have sufficient control over the device or network to essentially do a replay attack.
I’m basically saying that generating codes with TOTP and passkeys are a similar process and are subject to similar threats. Passkeys are slightly better since codes can’t be generated independently, but AFAIK that’s not a significant threat for TOTP anyway.
The choice between TOTP or passkeys is not a significant one, if your provider offers one or the other, your account will be reasonably secure. If your TOTP solution is built in to your password manager, it’s basically the same thing so you should probably prefer passkeys.
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.
sugar_in_your_tea@sh.itjust.works 5 days ago
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:
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.
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.