If someone gains access to your password manager, it is likely because you gave them access. If this was done under duress, there are bigger problems in the realm of physical security that are outside the scope of cybersecurity.
The assumption is that your password manager is only accessible on physical devices that you have authorized. The stored data is encrypted and will only decrypt upon being authenticated by whatever means you have setup (i.e. password, fingerprint, face id, etc.). The only way for a potential attacker to utilize an OTP generated by your password manager would be to somehow gain control of the physical devices where the password manager is installed and authenticate themselves as you.
As I understand, preventing such a scenario is not the purpose of MFA. Rather, it is to prevent the scenario where an attacker either attempts to brute-force guess your password to a particular application (or figures it out in some other way) and now is blocked by the inability to get passed the "enter the OTP code from your authenticator app" question.
---
The scenario that you ask about is a valid concern. It is just not the same concern as what is solved by OTP/MFA.
One area where the notion of separation of keys makes more sense is cryptocurrency, where if you have any serious investment in it, it is advised to set up a multi-key scheme. In such a case, even if somebody were to be forcefully required to allow a physical attacker to gain access to their password manager, there would still not be enough information there for the attacker to steal anything.
Right; if an attack gains access to your password vault, then one vector MFA can protect against (the multi-factor part) isn't valid. But that's not the only vector.
The biggest vector MFA protects against isn't really brute forcing (though it helps there); its password phishing. This is literally the only reason behind why Google's "account compromises dropped to zero after we required MFA internally" thing is a thing. Its easy to phish a password; but phishing MFA codes is a lot harder because, primarily, they're temporal. Phishing one is possible, but it would require the attacker to immediately use the code they phished, which significantly protects against broad phishing campaigns (as, automating a password phish + an MFA phish + logging in with that info within 30 seconds + navigating to the change password and remove MFA screen + phishing for a second and third MFA code to change the password and remove MFA is near-impossible). Spear-phishing can still be a threat vector, but its much rarer and also made more difficult.
> The biggest vector MFA protects against isn't really brute forcing (though it helps there); its password phishing. This is literally the only reason behind why Google's "account compromises dropped to zero after we required MFA internally" thing is a thing.
To be clear, there are phishing resistant authentication methods. Specifically:
1. Kerberos
2. Mutual TLS
3. Web Authentication
All other authentication methods (passwords, SMS, TOTP, QR code scan) are vulnerable to phishing.
Google's announcement about dropping to zero wasn't about adding just any new MFA (they already had MFA) but in mandating Web Authentication.
Some people get confused about phishing risk because passwords are vulnerable to passive phishing (e.g. log to file to attempt later), while the other mechanisms on this require active phishing (connect to a service in an attacker's browser, and parrot that authentication flow to the legitimate user). These active attacks are becoming more common, as you would expect.
Password managers greatly reduce the susceptibility to phishing because they care about the site that one is currently on; the person will have to perform different steps to release their password (or TOTP) to the wrong site. There is a proposal to put semantic tagging in SMS challenges such that platforms will only offer to auto-fill on the specified site for the same reason.
However, the three authentication methods above do not have user overrides such as manual SMS code entry - they simply won't work. You instead need to instead compromise the service, fronting application or hosting infrastructure/certificates.
That isn't to say that the phishing-susceptible secondary factors doesn't help the site in other ways. There is simply no good way to guarantee that someone isn't reusing their email and password on several other sites until the password shows up on a breach list. This is especially a problem for corporate logins (using corporate email addresses).
However, such secondary factors don't provide any benefit to the user with good password hygiene.
> (as, automating a password phish + an MFA phish + logging in with that info within 30 seconds + navigating to the change password and remove MFA screen + phishing for a second and third MFA code to change the password and remove MFA is near-impossible)
Well...
You get the MFA phish for free with the password phish, because the user actively expects to be prompted for the MFA code.
Automating a login with the information is easy, and automating the requests to change password and remove MFA is also easy.[1]
Phishing for followup MFA codes is a real obstacle, but probably not that difficult - assuming the source of codes is the same TOTP secret that was used for login, you can just tell your victim that their login failed and they should try again. That's a routine flow and it's unlikely to cause any alarm.
[1] Among other things, there are decent odds that you can't remove MFA because of e.g. a corporate policy. But you can just automate whatever it is that you want the compromised account to do, and do that.
> [1] Among other things, there are decent odds that you can't remove MFA because of e.g. a corporate policy. But you can just automate whatever it is that you want the compromised account to do, and do that.
The NIST 800-63 series has slowly been turning that ship around on ancient corporate password policies. The big step is to get the enterprise tooling to support newer policies.
Multi-factor doesn't need to mean the user has to go through multiple steps. Kerberos, Mutual TLS and Web Authentication all can use physical possession of the device (e.g. embedded TPM in your laptop or phone, USB or NFC key, lanyard smart card) as one of the factors, which means then you just have to enter a PIN or supply a biometric.
TOTP does not protect against phishing. Automating a phishing of a TOTP is not only not "near-impossible", there are SDKs sold on the black market that do exactly this for a modest fee.
