[m12k]

Just to verify - having TOTP-based 2FA enabled doesn't help in case of a password DB breach, right? Since the protocol is based on a shared password, which means an attacker would be able to generate valid tokens using the secret they got from the breach. (looks like there's work underway to make a breach-resistant alternative to TOTP[1])

This means that assuming the DB is using proper salt+hash, the main differentiator is the strength of your password. If it's a relatively short one that can be brute-forced/found via dictionary+small mutation, then attackers could possibly log in as you. If it's a strong password from a password manager, then that will likely have kept them from being able to crack your password.

Of course all this only has value if we assume that only the password db was breached. If they managed to access the place your env-var/secrets are stored, then all bets are off.

[1] https://www.mdpi.com/1424-8220/20/20/5735/htm

[jrochkind1]

I don't understand enough about the protocol to judge your claim, but it's challenging my assumptions about what 2FA is for. If 2FA with TOTP does not protect you in cases where the attacker knows your password... what is it for? I thought that's what it was for.

[bigDinosaur]

The server also contains the secret, so if that secret is leaked then the attacker can generate new tokens. It protects you in the case that your password was stolen, but nothing else e.g. via phishing.

[jrochkind1]

OH, I see, thanks. The password and TOTP secret are separate, but you're suggesting they may likely both be stored in the same place such that a breach could give attacker access to both. Tell me if I don't have it right.

It occurs to me that I know how to reset my password most places I log in to, but I actually have no idea how to reset the TOTP secret.

[bigDinosaur]

It might be stored separately, the issue is just with an uncontained breach I suppose.