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. They may hope I'm using my phone, but they can't know. And they shouldn't. My security, my business.
Overall there are 2 cases to consider: one where a compromised users screws the user, and one where a compromised user screws the service.
In the first case, which is most online services, the only reason the service cares about the security of an account is to protect the user. They have no business policing how said user handles their own security. Propose and nudge, sure, but verify? That goes one step too far.
In the second case, which would be most enterprise networks, I would recommend that the company issues a security key to each employee, and ensures (with some form of remote attestation if need be) that employees log in with that key.
In scenario 1, I can see the reasoning if we’re talking a low value account e.g. pseudo-anonymous account that holds no personal/financial info. In this case the service isn’t worried about you but the platform as a whole where a person or group can control many accounts
Scenario 1.5 is non enterprise but with a financial or something of value aspect e.g. rewards/loyalty programs. The service has to protect against fraud
Scenario 2: if we’re having this discussion about the need for MFA, how it ties us to devices and all the other reasons mentioned already, then using a security key with remote attestation is even more difficult for the end user. I don’t see how this is an improvement. It is in fact MFA itself, just with a different, more cumbersome, type of factor
How exactly in scenario 1 would the service protect itself against sock-puppets? How can they make sure that two different accounts are tied to two different users? How do they prune "false" accounts? We see that kind of stuff being done by Facebook for instance (real name policy), and it has basically nothing to do with MFA.
In scenario 1.5 the service has to make sure users are protected. I believe it is counter productive there to force users beyond some reasonable step. For instance, it would be unacceptably discriminatory for a bank to require users to have an Android or iOS phone application to be able to make payments online. (Flip phone users should not be second class citizens.)
Scenario 2 is almost exclusively about employees. Issuing hardware to employees is not difficult. I have 2 company-issued laptops, one from my company, one from my client. If my client wanted to increase security, it would be trivial for them to just give me a USB security key, and it would be trivial for me to just plug that key and touch it whenever there's a pop-up saying I should touch it. I don't see the difficulty here.
In fact, given the choice of installing Okta on my personal phone, or using a security dongle, I would take the security dongle every time. Not only does it better separate work stuff from personal stuff, it's actually more convenient.
> 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.
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.
> 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.
> 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.
Overall there are 2 cases to consider: one where a compromised users screws the user, and one where a compromised user screws the service.
In the first case, which is most online services, the only reason the service cares about the security of an account is to protect the user. They have no business policing how said user handles their own security. Propose and nudge, sure, but verify? That goes one step too far.
In the second case, which would be most enterprise networks, I would recommend that the company issues a security key to each employee, and ensures (with some form of remote attestation if need be) that employees log in with that key.