Doesn't this break the purpose of MFA, which is that the thing you know (password) is separate from the thing you have (MFA device)? If so, then why do all of the reputable password managers include TOTP functionality?
Short answer: Password managers offer this funcionality because there is a demand for it.
Long answer: In practice, TOTP schemes are used (from a webadmin point of view) just to stop credential stuffing attacks [1].
There is very little additional security in generating TOTPs on a dedicated device, such as a smartphone, compared to generating them on the password manager itself. Threat models in which a separate setup would have a benefit include only breaches of your password database itself.
For savvy users with unique passwords, protecting against that threat model offers little benefit at a significant convenience penalty, as such attacks are unlikely to begin with. If MFA with hardware tokens is not an option, then it might not be worth the hassle of TOTPs.
As such, password managers that offer TOTP are useful in scenarios where using TOTP is mandatory and does not provide security benefits.
Actually interestingly point number one probably holds true, since very few GUI password managers actually document their threat model at all and actually evaluate their design decisions accordingly.
E.g. typical browser extensions if used with no additional confirmation allow easy local exfiltration of passwords. Particularly if actual user input on each request is needed TOTP would provide additional benefits (similar to your fido key button press). Password managers often compromise the effort of a single click for much less security of autofill.
Depending on your perspective, a password manager with autofill could actually be more secure.
If password managers autofill or suggest accounts based on matching domain, then you're insulated from phishing attacks due to not validating the domain. If you always copy-paste your credentials, you are relying on your own perfect vigilance in checking the domain when pasting the password for the intended site into the actual site. By using autofill or autosuggest, the computer is checking the domain for you and the failure to autofill or find related credentials can indicate a phishing attempt by disrupting your expectations.
TOTPs are also a defense against phishing leading to persistence.
You can't phish someone and then lock them out of their account by changing their login details.
Other second factors (like ubi-key) are better against phishing because they are cryptographically linked to the domain. This does require some form of challenge-response.
I'm not sure this is a meaningful threat model. "Well, the adversary can authenticate as me but they'll have to reauthenticate to change my credentials so I'm a little bit safe" is a major stretch. You've already been pwned at that point and not a lot of services force a 2FA step on actions post-login.
There's also the fact that it helps to somewhat mitigate phishing, in that they'll only offer to autofill the code if the website domain matches the one on file, like they do for the password.
I am not an expert, but "Threat models in which a separate setup would have a benefit include only breaches of your password database itself." doesnt this mean that there is a big difference if the attack vector is by a keylogger? (Which can sniff the Database pw). Are keyloggers not a common thing for threats (I dont know)?
If the key logger is in a peripheral then the TOTP/password manager can still protect from replay attacks. If the key logger is on the computer then it has access to the password vault and the vault secret.
If your password store is owned then the attacker has both your credentials and the second factor. So in that way, the password manager has sacrificed a security fail-safe.
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.
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.
The team from 1password did a nice writeup, when they introduced storing TOTP in their password manager.
Gist is: Most people treat TOTP as a second, time based password (multi step authentication) instead of a second factor. If you truly want 2nd factor, you should never sync your passwords to the phone you are using as 2FA, and never use your passwords on the phone you are using as 2FA.
So it depends on your own security concerns if you want to treat TOTP as a true second factor or as a secondary, time based password only.
They are significantly more locked down and it's hardware more strictly controlled than most desktop OS's, so I would say that assumption is correct.
It is looking as though desktop OS's will catch up in this regard considering the progress that's being made with immutable root filesystems and sandboxing with permission sets for user facing programs.
Personally I feel it’s a bit weird when people keep their TOTP on the phone they use to access the service that requires the token. If the idea was to keep things seperate, then either your phone shouldn’t when the tokens, or it shouldn’t be used to access secure services.
Hardware token still feel like the safest option, but I also don’t what 8 different token generator in my pocket.
> and never use your passwords on the phone you are using as 2FA
Notably, this also involves not logging into the same email account that you use for signups - it would allow the attacker to bypass the password manager completely by requesting a password reset.
I guess you could solve this by having one email address for signups and another to communicate with people, but you would still be giving up email notifications (such as “your order has been shipped”) delivered to your phone.
The whole thing you know. / thing you have is very outdated thinking. It made sense as a way to explain it 20+ years ago when 2fa was primarily done with physical RSA fobs, but it makes no sense in the modern world of TOTP, password managers, etc.
For one thing, TOTP any it’s nature isn’t tied to a thing I have. Heck - you could build a TOTP token web service accessible from anywhere, it’s just an algorithm.
Secondly, if you’re using a password manager, you likely don’t know the password, so that part doesn’t fit either.
And if you insist on still fitting that square peg into todays round hole: The thing I know is my password managers’ decryption key, and the thing I have is my laptop / iPhone.
Exactly. The thing I have is whatever device I'm using right now - could be my PC, my work laptop, my phone, or any other system I can plug a USB stick into. And the thing I know is - well I don't really know it at all - it's whatever whichever device I'm using spits out when I tell it to tell this other thing what I supposedly 'know'.
And then the remote system, trying to be ultra-secure, says "ok we'll send you an email/message and you need to confirm that". But that third factor message comes in on the exact same device I'm using for both the first factor and the second factor.
It's all just security theater.
Conceptually, it kinda makes sense. Like when using a credit card, require the name on the card, expiration date, billing address, and CVC instead of just the number.
But in practice, eh. We have nothing similar to the financial system to catch fraudulent ID usage. So it's all just extra annoyance. For practicality, almost everyone will end up with everything just being a single factor.
Yes but you transmit the website password, so it’s possible for an attacker to gain access to that website through a data leak or through brute force, without gaining access to your password manager. Sure, they could do the same if they got hold of your TOTP secret, but that’s never transmitted (except at setup).
95% of the security of TOTP stuff is that users have no freedom in implementing it and thus cant mess it up. There is no equivalent of having "hunter2" as your password when the user doesn't choose the secret. They cant reuse secrets across sites if they dont choose secrets.
Every other realistic threat is not helped by TOTP. There is some threats that in theory TOTP can help with, but dont given how it is used on the web.
* phishing - just as easy to phish the token
* trojan on your computer/shared workstation - just steal the session cookie or take control of browser remotely
(For U2F/fido keys/webauth based 2fa the situation is a bit different, but almost nobody uses that)
Its debatable how bad that is. For most (not all) people, the realistic threats do not have physical access to your computer.
However, this is kind of my point - you might put your password on a sticky not. In TOTP 2FA the equivalent is your qr code. I have never seen anyone print out a qr code and put it on a sticky note beside their computer.
Side question: why is nobody losing their minds over the fact that almost all other MFA actions rely on your phone, which almost always has access to critical services (banking, work mail, personal mail, possibly ssh, etc).
I’m more concerned about losing my Device as many MFA tokens are not backed up in apple ecosystem.
Given the preference I’d rather not carry around an additional phone or hw token. But I fully understand those who don’t appreciate it.
You can possibly force bespoke token apps into google Authenticator or the ms variant if they use standard Totp or hotp (ms auth on AAD does not by default but you can force it to provide one during the workflow).
This is such a big frustration I have with phone based 2fa. It's obvious that the people that push for this are from the first world and have never been mugged or even worried about it.
For me I weighed the risks and decided that losing my phone and getting locked out of services with 2FA was a more realistic problem than someone compromising my password manager.
I still use 2FA when it's available because it still protects against an individual password leak.
Readit News
Long answer: In practice, TOTP schemes are used (from a webadmin point of view) just to stop credential stuffing attacks [1].
There is very little additional security in generating TOTPs on a dedicated device, such as a smartphone, compared to generating them on the password manager itself. Threat models in which a separate setup would have a benefit include only breaches of your password database itself.
For savvy users with unique passwords, protecting against that threat model offers little benefit at a significant convenience penalty, as such attacks are unlikely to begin with. If MFA with hardware tokens is not an option, then it might not be worth the hassle of TOTPs.
As such, password managers that offer TOTP are useful in scenarios where using TOTP is mandatory and does not provide security benefits.
[1] https://en.m.wikipedia.org/wiki/Credential_stuffing
E.g. typical browser extensions if used with no additional confirmation allow easy local exfiltration of passwords. Particularly if actual user input on each request is needed TOTP would provide additional benefits (similar to your fido key button press). Password managers often compromise the effort of a single click for much less security of autofill.
If password managers autofill or suggest accounts based on matching domain, then you're insulated from phishing attacks due to not validating the domain. If you always copy-paste your credentials, you are relying on your own perfect vigilance in checking the domain when pasting the password for the intended site into the actual site. By using autofill or autosuggest, the computer is checking the domain for you and the failure to autofill or find related credentials can indicate a phishing attempt by disrupting your expectations.
Other second factors (like ubi-key) are better against phishing because they are cryptographically linked to the domain. This does require some form of challenge-response.
2FA will offer little failsafe in such a scenario.
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.
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.
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.
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.
Deleted Comment
Gist is: Most people treat TOTP as a second, time based password (multi step authentication) instead of a second factor. If you truly want 2nd factor, you should never sync your passwords to the phone you are using as 2FA, and never use your passwords on the phone you are using as 2FA.
So it depends on your own security concerns if you want to treat TOTP as a true second factor or as a secondary, time based password only.
https://blog.1password.com/totp-for-1password-users/
It is looking as though desktop OS's will catch up in this regard considering the progress that's being made with immutable root filesystems and sandboxing with permission sets for user facing programs.
Hardware token still feel like the safest option, but I also don’t what 8 different token generator in my pocket.
Notably, this also involves not logging into the same email account that you use for signups - it would allow the attacker to bypass the password manager completely by requesting a password reset.
I guess you could solve this by having one email address for signups and another to communicate with people, but you would still be giving up email notifications (such as “your order has been shipped”) delivered to your phone.
For one thing, TOTP any it’s nature isn’t tied to a thing I have. Heck - you could build a TOTP token web service accessible from anywhere, it’s just an algorithm.
Secondly, if you’re using a password manager, you likely don’t know the password, so that part doesn’t fit either.
And if you insist on still fitting that square peg into todays round hole: The thing I know is my password managers’ decryption key, and the thing I have is my laptop / iPhone.
And then the remote system, trying to be ultra-secure, says "ok we'll send you an email/message and you need to confirm that". But that third factor message comes in on the exact same device I'm using for both the first factor and the second factor.
It's all just security theater.
Conceptually, it kinda makes sense. Like when using a credit card, require the name on the card, expiration date, billing address, and CVC instead of just the number.
But in practice, eh. We have nothing similar to the financial system to catch fraudulent ID usage. So it's all just extra annoyance. For practicality, almost everyone will end up with everything just being a single factor.
Doing 2FA correctly in isolated hardware is expensive. We traded adoption for an imperfect implementation.
---
[1] https://en.wikipedia.org/wiki/Top_of_the_Pops
Every other realistic threat is not helped by TOTP. There is some threats that in theory TOTP can help with, but dont given how it is used on the web.
* phishing - just as easy to phish the token
* trojan on your computer/shared workstation - just steal the session cookie or take control of browser remotely
(For U2F/fido keys/webauth based 2fa the situation is a bit different, but almost nobody uses that)
However, this is kind of my point - you might put your password on a sticky not. In TOTP 2FA the equivalent is your qr code. I have never seen anyone print out a qr code and put it on a sticky note beside their computer.
I’m more concerned about losing my Device as many MFA tokens are not backed up in apple ecosystem.
The architecture is flawed for conveniences sake.
You can possibly force bespoke token apps into google Authenticator or the ms variant if they use standard Totp or hotp (ms auth on AAD does not by default but you can force it to provide one during the workflow).
Anyways, you are supposed to stash your recovery codes somewhere (not on the phone).
I still use 2FA when it's available because it still protects against an individual password leak.