|
> If the password database leaks, the TOTP shared secret can be used by attackers (one can't hash the TOTP shared secret like we do passwords) OTP secrets are stored encrypted, not in plaintext. > they'll be barred from doing important operations like changing the password, if the service asks for the TOTP code for such things. Yes, that's what "help" means here. OTPs limit the access lifetime and rights of the session. They help. They're strictly better than a password alone, whereas you claimed they're "not more of an MFA than using the password alone". To reiterate: 1. The password to unlock a password manager isn't MFA for the services the password manager protects because it's part of the authentication flow of your local system, not of those services. This is also why it does nothing to combat phishing, brute force attacks, or data breaches. 2. Where OTP secrets are stored, on the other hand, is irrelevant for those same threat models. Their value, limited as it is, is the same either way. In fact, if you use a password manager with OTP autofill and never type codes in by hand, you're basically doing as well against phishing as people using FIDO. But again, U2F and FIDO2 are strictly better. |
Then so are password hashes. I mean, it would be pretty stupid to make the effort to encrypt part of the login information, and then fail to encrypt the other part.
> Yes, that's what "help" means here. OTPs limit the access lifetime and rights of the session. They help.
Yeah, yeah, they do. How much? "Hardly" In my opinion.
Here’s the thing with TOTP: it’s time based, and therefore remains valid for a couple dozen seconds. Unless the service took special steps to make sure TOTP codes aren’t reused, the MitM can reuse your first TOTP code to change your email & password behind your back, close the session, and lock you out forever. They’d have to be fast, but machines are pretty fast these days. And even if the service does take such precautions, nothing prevents the MitM to ask you for a second TOTP once you make a less than important operation, and if you’re tired enough you’ll just grumble and give it to them.
Point being, there are ways to do long term damage even in the face of TOTP, which are only barely harder than password-only attack.
So sure, TOTP does help. They even help me, by a negligible little bit. But honestly it’s zero vs epsilon as far as I am concerned.
> 1. The password to unlock a password manager isn't MFA for the services—
Irrelevant.
MFA means multiple factors are required to log in. If I’m putting a password in my password manager, I need something I know (master password), and something I have (my password database). That’s 2 factors no matter how you cut it. Whether the service I’m using knows about those 2 factors is immaterial.
> 2. Where OTP secrets are stored, on the other hand, is irrelevant for those same threat models. Their value, limited as it is, is the same either way.
Agreed.
> In fact, if you use a password manager with OTP autofill and never type codes in by hand, you're basically doing as well against phishing as people using FIDO.
Indeed.
> But again, U2F and FIDO2 are strictly better.
They are, if only because the service can be more confident this translate to decent security practices from the user (or at least the user’s machine). And they can be quite non-intrusive, which I like.
I’m wary however of the temptation to use those new credential mechanisms to lock users in. Require FIDO2 if you want, but do not require me to buy a security key from a specific brand (even if it’s the TPM), or store my credential database in some Apple Cloud Shit.