[FreakLegion]

> And storing my TOTP code in the same password manager I use to store my GitHub password is not more of an MFA than using the password alone.

Of course it is. Unlocking your passwords in KeepassXC isn't MFA in this context because it's completely orthogonal to phishing, brute force attacks, and data breaches. OTPs are far from great but help with all three, no matter where you store them.

[loup-vaillant]

Oh yeah? How does that help exactly?

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). Phishing? They can just take my TOTP code and redirect it to the legitimate service. I may be able to stop them by asking the service to end the session (if I even find how to do that), but as long as the session is up they can do pretty much whatever they want. At best they'll be barred from doing important operations like changing the password, if the service asks for the TOTP code for such things.

The only thing TOTP really mitigates is brute force attacks, and they do so only for people who use weak passwords. Since I'm using randomly generated passwords with over 120 bits of entropy, I'm basically immune to brute force to begin with.

We have much better than TOTP to stop those attacks.

[FreakLegion]

> 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.

[loup-vaillant]

> OTP secrets are stored encrypted, not in plaintext.

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.