Ask HN: Why do password managers have TOTP? | Hacker News Reader

Ask HN: Why do password managers have TOTP?

139 pointsdaenz119 comments

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?

View on HN

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.

[1] https://en.m.wikipedia.org/wiki/Credential_stuffing

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)?

Not sure how common it is but if the endpoint is compromised to the point of having a keylogger installed then it's basically already game over.

Ah, I think I get the point, but is it really like this? The attacker would have to do everything through the endpoint, isnt this cumbersome for the attacker?

It would be, but if they had a keylogger installed then the endpoint is completely owned, in which case they could just exfiltrate the password database from memory. Or they can just pilfer authentication/session tokens directly once you logged in. More generally, making things more cumbersome (in the sense of requiring more steps) doesn't really provide any meaningful security since it can generally be automated anyway.

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.

If your password store is owned, you’re fucked. Period.

2FA will offer little failsafe in such a scenario.

Why so? If you don't have second factors in your PW store, then any service which actually implements MFA properly shouldn't let anyone have access to anything.

Not quite, that's why 2FA is supposed to be a second factor, not just extra data in the same place.

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.

> If your password store is owned, you’re fucked. Period.

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.

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.

I think that auto-suggest, meaning the password manager only suggests a password, but you need to actively click on the suggestion in order for the password to be entered, would satisfy both requirements: mitigate phishing and exfiltration. This is the default for 1password.

This is also the case for bitwarden. I think it's only browser built in autofill that does it proactively

Bitwarden has an auto fill option, though it was off by default last I checked. LastPass too has auto fill yet mitigated by requiring a click to populate the match.

> LastPass too has auto fill yet mitigated by requiring a click to populate the match.

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.

The problem is not on the browser interface side but on the interface of the secure password store: here you would need to give your ok (like with a hw key). At least in my password manager it seems possible to impersonate the browser after extracting the shared communication token and then query the whole database once it is unlocked from a random client.

What's the threat model you are considering?

Well considering that the local password managers make a great fuzz about memory randomisation and protection of localhost communication, I would consider a trojan running under user privileges a threat myself that a password manager should address. Otherwise it seems little better than a plaintext password file saved on an encrypted hard drive. However, my point is that mostly I just want to know what the software is good for, ie. protecting me against.

I remember KeePass had a feature where the autofill was supposed to be safe against key loggers (as opposed to typing out the password yourself)

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 disagree on phishing protection. In the best case the phisher has 30 seconds to login, and then has enough time to change the login details.

The point is that changing login details often requires the 2FA. And I presume that a TOTP cannot be used twice.

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.

Most services I have used actually did require 2fa on authentication relevant changes post login. That's why I mentioned this slight protection.

I'll grant the threat model is of marginal relevance.

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.

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

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

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.

https://blog.1password.com/totp-for-1password-users/

I've always assumed (possibly incorrectly) that my phone is more secure than my desktop.

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.

A hardware security key would allow you to have one thing in your pocket, used for many sites.

Depends on your phone. But it’s also WAY more likely that your phone gets stolen than your desktop does.

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

The "modern world of TOTP" wasn't some advancement in thinking. It was cost.

Doing 2FA correctly in isolated hardware is expensive. We traded adoption for an imperfect implementation.

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

As a Brit of a certain age, I hate the term TOTP in this context, as it will always mean to me 'Top of The Pops'[1] ;)

---

[1] https://en.wikipedia.org/wiki/Top_of_the_Pops

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)

But then users store these passwords on a sticky note attached to their display device…

Which is pretty good against some real threats. Evil maids are very rare in comparison to credential stuffing.

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.

The architecture is flawed for conveniences sake.

Use something like Authy. It supports Backup.

Anyways, you are supposed to stash your recovery codes somewhere (not on the phone).

This is really annoying with employers who assume they can use your personal phone as part of their MFA fig leaf.

Especially when it isn't plain TOTP but some custom app.

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.

Because some sites/companies force people who do not want MFA to use MFA, and people aren't willing to sacrifice convenience for security like that.

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

One use case for password managers is account sharing among multiple people. Password managers make more money if they support that use case, which provides legitimate value in companies and families

Worth noting that a lot of services now force MFA even if the user doesn’t consider it important enough to warrant it (MFA is always a trade off between security on one side, and convenience and the risk of losing access entirely on the other hand)

Putting a TOTP code in a password manager is in many was a way of turning off MFA for services that don’t let you do this.

Where exactly are people supposed to store their recovery keys? I get that theoretically it’s supposed to be cold storage.

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.

I think being targeted by government or a similar class of advanced threat is not something you should really think about when choosing how you manage passwords, as they will have many ways to target you that don’t involve password compromise at all. Password managers and MFA are about protecting from account compromise by run of the mill cybercriminals. Storing recovery keys on a piece of paper in a safe place is perfectly fine for that class of threats.

If you are actually targeted by the government they'll pwn you with zero days on your browser or whatever. No authentication scheme will save you at that point.

Real users should protect against credential stuffing and, if they can manage it, phishing.

Considering I don't know my passwords, nor can I generate TOTP codes off the top of my head, both are "things I have" for me (a password manager + TOTP manager). And because of this, I prefer to keep the two things separate. That way you need to compromise two services rather than just one.

Realistically though, once an attacker's gained access to your computer or phone, there's very little you can do to prevent them misusing that data. You can keep your TOTP on a second device encrypted with a Yubikey that you keep in a vault in Geneva, but it's not overly useful when an attacker can simply call your bank and read out the security reset SMS they sent you/him.

I'm happy to hear from security power users if there's anything I'm missing.

I asked this question on the 1Password forum 3 years ago, and thought the responses were interesting:

https://1password.community/discussion/101714/why-is-it-a-go...

If you are really strict about 2Fa, then in theory you would never be able to use your phone that you use for TOTP generation to login to Websites that use this TOTP Code either.

So I'm pretty sure I already broke this separation due to convenience. So might as well put it in my PW Manager.

IPhone/android is much More secure than a browser extension or windows, even macos.

Attack surface is much larger.

It's slightly less secure, in the sense that if someone gains access to your password database they'll have access to your MFA codes as well. The only scenario this would really matter in is if something like your phone or laptop was stolen, but not both, and they already could unlock your database file.

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.

If you lock your password manager with a hardware security key, you get the best of both worlds. The NFC Yubikey works well in this niche.

I think that you are right, but I don't want 2FA, so I use the TOTP from my password manager.

Also, I think that we should be able to reset a regular password with a TOTP?

Why do we need email?

It usually doesn't except when your threat model includes a scenario where physical compartmentalization is supposed to prevent giving up the secret under duress (you don't carry the out of band device with you to wherever you go). But in that case you're better off being able to plausibly deny the existence of that secret (or the communication channel) in the first place.

I personally have a second password database that generates my MFA codes. I only open that on my phone (because I think the KeePass desktop app doesn't support TOTP out of the box).

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.

KeepassXC supports TOTP

KeePass supports TOTP out of the box without any plugins since the 2.47 release in January 2021: https://keepass.info/news/n210109_2.47.html

Usage: https://keepass.info/help/base/placeholders.html#otp

Oh that's nice, thank you!

I really like having totp functionality. I use a yubikey for TOTP and boot into an air gapped machine with keypass to store the TOTP codes in case I lose or break the yubikey. I don’t store TOTP codes in my main password manager, but it’s not completely insane. You’re screwed if someone gets your decrypted password database, but you’re still protected from most other attack vectors.

TOTP and MFA are 2 different things even though they are often used together.

MFA is all about having a second physically held device to authenticate, TOTP is one of the mechanisms by which this is done.

Not everything needs MFA, however it is often mandated so having the ability to generate TOTP in a situation like this (such as when an account is shared and pure security is not crucial) is convenient.

Depends on type of attack/level of security vs convenience. Having both username, password and TOTP in you password manager protects against password leaks from cloud services, but not from someone stealing/getting access to the content of your password manager. Having TOTP on separate device protects against both, but is also a bit more inconvenient in daily use.

Different people have different goals. Just because a buyer for an organisation or a provider of a service wants users to use TFA doesn’t mean the users want to deal with it.

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 think it’s a decent enough balance for most people.

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.

> bigger things to worry about

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 a hacker is in your system enough to get totp keys, they can also just pay themselves from your bank account after you log in.

Important documents, source code, emails, ssh keys, you name it.

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.

> swapping out login pages

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.

I keep TOTP in my password manager, but my password manager is encrypted with a hardware key, a PIN code, and even getting the encrypted files depends on getting into my private git server.

I also only use TOTP on sites that don't support u2f/fido/webauthn or implement it badly (like amazon that only allows a single key).

What happens if you lose the hardware key? Is there a recovery mechanism?

Standard practice is to have two if one breaks or is lost.

I have multiple, both for that scenario and for different computers. I also have a USB stick with the root key for issuing new keys if all my hardware keys break.

You can actually use multiple security keys on AWS I found out. It requires you to use the yubico authenticator app though. Essentially your security key stores the MFA secrets on it, and the yubico authenticator app accesses them for TOTP. You can register multiple keys in the authenticator app. So even though you can only have one MFA virtual device in AWS, that one virtual device is backed by multiple keys.

Then you don't get the strong phising protection though. One of the reasons U2F/webauthn is great at phising protection is that the key verifies the sites domain. IIRC there has only been one good attack against that and even that required the user to allow webUSB for the phising site (and it has been patched).

True. I can't think of any good reason why AWS limits MFA to one device...seems like a very silly oversight to be honest.

I agree.

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.

You don't use your password manager on your phone? ;)

under a different account that doesn't have the password to it stored in the password manager. yes.

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

What kind of attack does it make possible that is impossible without TOTP in the password manager?

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.

I keep TOTP separate on my phone. Password database will be decrypted in memory after it's unlocked and can be dumped with sufficient privileges.

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 depends in part on the OS and how easy it is to go from any remote access to full password manager access. On most desktop systems it is very easy the next time the password manager is used, so a true second factor gives you more time to detect a remote breach of your account before getting locked out of all of your accounts. Everything you access between the breach and you discovering it could still be compromised (where compromised can mean the account is gone for good) so it is of limited use in practice but not necessarily useless considering the complexity of software that access the network (of course it can be nearly impossible to detect a breach but often isn't in practice). It would be much more effective at protecting access to accounts if there was a distinct account change TOTP vs. the regular one for login (or, say, one to make small purchases and a different one for larger money transfers), but I've never seen that. If you don't access financial accounts every day it can give you some time to detect the breach if you are lucky.

TOTP = Time-based One Time Password.

MFA = Multi Factor Authentication.

For those who didn't know, like me. I wish acronyms were less used or at least described when introduced. Like Elon Musk once said:

"Don't use acronyms or nonsense words for objects, software or processes at Tesla. In general, anything that requires an explanation inhibits communication. We don't want people to have to memorize a glossary just to function at Tesla."

Ha, I went and researched this too, thinking I'd post the same basic comment. Should have read a little further. In general, I think it's good practice to do like the newspapers and define an abbreviation on first usage (which in this case would be the original post).

Because a password manager isn't the only way a password can get exposed, and having a secure way to save your TOTP secrets is not a bad idea either in case you lose your hardware key.

Your laptop is a second factor device. You don’t need to reach for your phone to log into anything with 2FA. Use a program on your laptop so you can get a TOTP code with a keystroke.

Because nobody, not even fancy techies, really cares about security, they care about "good enough" and all the usability they can get.

Could you unpack the TOTP Acronym, please? I’m sure that it means something to you but it is not obvious nor as widespread as you may think.

Time based One Time Password. The app or password manager stores a secret, which when combined with the current time yields a OTP.

https://en.wikipedia.org/wiki/Time-based_one-time_password

We use it on shared accounts (sometimes they are inevitable) Before this feature, we had to rely on backup codes.

If it was on a different app on the same device, it still wouldn't be the 2FA you're talking about.

I work for an MSP who uses the MFA function of a password manager to access customer accounts, this means 2FA codes can be shared across teams of people and offers significant protection against credentials being stolen as they can't be used once access is revoked to the password manager. We turn off exporting the MFA codes so that also can't be stolen.

I agree otherwise all we’d need is a TOTP master password, and login to a service without password

A password manager (database) is not something you know. It's something you have.

The issue is that if someone gains access to your password manager then they have both your password and your totp secret. The whole point of MFA is that these should be different things.

If someone get access to my password manager, I’m screwed anyway. It contains far enough information to bypass any MFA of any service.

Well isn’t that a problem in itself then?

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.

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.

I disagree that storing these separately is “the whole point of MFA”. Passwords can be hacked in a number of places, not just client side or in the password manager, so TOTP mitigates MITM style attacks where the password is known by an attacker but it was not gained from the password manager or the site. I certainly get that separating them would be theoretically better, but with TOTP in my password manager I end up using TOTP everywhere.

Good point. I'd agree that totp on phone > totp in pw manager > no totp, so using it in some capacity is definitely better than not using it at all.

I think that’s true as long as you never upload it to cloud, but keep it either on one device only or manually sync across more devices.

Because users want it. Quite simple.

What users want > What is good practice.

What's TOTP?

I agree, it makes no sense to have them stored in the same password manager.

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.

But both apps are on the same user devices, presumably? If so I can see that splitting them protects against the 1password DB being compromised but not against someone getting access to a user’s phone (which seems more likely to me).

Reply on news.ycombinator.com