Ask HN: Why do password managers have TOTP?
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?
123 comments
[ 4.3 ms ] story [ 196 ms ] threadAlso, I think that we should be able to reset a regular password with a TOTP?
Why do we need email?
(Probably also because some people really don't get the point of 2FA and demand that feature, but the above is enough of a legitimate reason to support it.)
The way I understand it, the password database should only contain the passwords; then if someone got access to it (or your email app, same thing, as they would just do a password reset) 2FA would still protect you.
I'm not considering online password managers which IMHO are inherently weaker than local ones.
If somebody steals my laptop the passwords database is protected by a master password anyway.
You could argue that an attacker with access to copy the password DB can intercept OTP as they are entered, but that seems much more work than running off with everything at once.
It’s still something you know plus something you have. If your credentials are somehow intercepted, you’re still covered.
Presumably it only falls down in the event your machine is fully compromised at which point you have bigger things to worry about.
With that said, it’s worth having separate 2FA setup on your actual password manager.
Do you mean things like seeing your photos?
If your 2FA is not stored on the same machine then the attacker won’t be able to log into your bank / brokerage account, and that’s something I consider the main thing to worry about.
If your machine is compromised, it’s game over. What’s to stop an attacker intercepting your 2FA codes by swapping out login pages for services you use?
TOTP via PW manager is safer for most people than SMS based 2FA. Having your login codes on a separate device is better still but it’s a trade off with convenience. For some people that won’t be worthwhile but then it’s a question of threat model.
Hmm you’re right, I didn’t think of the scenario when they would give you the machine back in a tampered state.
I was gonna reply “well just wipe it once you get it back” but that assumes that I know it happened, so I’m still susceptible to the evil maid attack and such.
Also fully agreed with the last paragraph.
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.
Suppose you’re actually targeted by government, and you want to protect access you only have two possibilities.
Store it in encrypted cold storage that people that are targeting you have access to or forget them altogether and lose access yourself.
I feel like people have forgetting what is actually being protected from.
Most MFA apps on iOS either store the keys in iCloud Keychain or some some third party sync service or not at all when your phone breaks.
I think the threat model isn’t well thought through at all.
An offline encrypted keystore doesn’t in fact have a worse security characteristic than most options listed above.
And yes theoretically an hsm is better but realistically speaking I think a physical key that I carry around every day isn’t almighty either.
Real users should protect against credential stuffing and, if they can manage it, phishing.
I use password manager for passwords.
Use my phone for lower security TOTP codes, and a hardware key for things I was slightly more secure.
I also use a standalone 2FA for access to me password manager.
Also, my work accounts are stored in a different password manager and THEY use 2 more different 2FA clients...
its starting to get a bit much tbh
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.
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.
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.
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.
One of the things I like about 1Password is that we were able to switch off the built in TOTP for our whole organisation, and force all TOTP codes to go via Duo Security. Thereby forcing a separate 2FA app.
Practically I'd say that using the TOTP functionality of your password manager is such a big win for the average user that I'd advise people use it without hesitation.
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.
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
2FA will offer little failsafe in such a scenario.
If your second factor is on separate hardware then even total compromise of the first piece of hardware (the laptop containing the password database) is not sufficient.
The separate hardware could be many things. One is something like yubikey etc. Or a separate computer with the TOTP secrets, etc.
Factually incorrect. In that scenario, REAL 2FA (the kind not stored in the password store) is the only thing keeping bad guys out until you change passwords.
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.
Actually, if you login/authenticate to LastPass, it will automatically autofill the forms within all of your open tabs. It's quite irritating--I haven't figured out a way to disable it.
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'll grant the threat model is of marginal relevance.
So I'm pretty sure I already broke this separation due to convenience. So might as well put it in my PW Manager.
Attack surface is much larger.
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.
This is sort of like asking why do defence attorneys defend their client of the prosecution wants to convict them or why stores have security cameras if I want to take their stuff for free.
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.
Anyways, you are supposed to stash your recovery codes somewhere (not on the phone).
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).
I guess in this case it's like a second password. Only really useful if someone only manages to bruteforce/spy my main master key but not the second one, right?
Would love to hear opinions on this, I might be missing something.
Usage: https://keepass.info/help/base/placeholders.html#otp