3. Data breaches. Where you store your TOTP secret doesn't matter unless your password manager backs up online, that's what gets breached, and the data isn't properly encrypted. Which has happened.
4. Malware. Where you store your TOTP secret matters. This is why U2F and FIDO2 have a user presence test, but the real-world value here is overstated. Malware can always just steal your tokens.
5. Physical access. Where you store your TOTP secret matters. If you care about security though you'll have other measures in place to keep someone with physical access out, which is enough against basically anyone except governments.
Summary: A "true" second factor doesn't really matter. What matters is deciding which scenarios you care about and making sure you have security you'll actually use given those constraints.
I’d add another risk here because I think it’s the main one the TOTP actually ends up protecting against in this case: Credential Stuffing.
Since the TOTP secret is generated by the service and not the user, it prevents credential stuffing. It can’t be reused between sites. If you’re still reusing the same password on every site this is a huge increase in security given how many services are breached.
… but using a password manager and a unique password for each service already does that.
So storing your TOTP secrets alongside your password in your password manager is a _very_ marginal benefit. Prevents a replay of the login if it got captured in the clear and… not much else I can think of.
Where-as a “true” 2FA adds protection against malware, data breaches, physical access, and other risks. That seems like a pretty big benefit for minimal work.
I think for most people using TOTP to avoid the “this shady download/keylogger controls my entire life now” scenario is a pretty clear win on effort versus risk.
So I mostly agree with what you wrote here except the summary. I’d say everyone should be using “true” TOTP where they can, and if you’re going to store them alongside your password they’re little more than security theatre so don’t bother.
For the most part, 2FA is just a hack to mitigate the fact that passwords are a weak form of authentication: people reuse passwords, and websites leak them.
They're better than nothing, but outside of enterprise contexts (e.g., enterprise-managed CAC cards and other hardware tokens), I think expecting 2FA to defeat malware, physical access, etc. is too much.
> For the most part, 2FA is just a hack to mitigate the fact that passwords are a weak form of authentication: people reuse passwords, and websites leak them.
Yep, and "using a password manager with a randomly generated password for each site" already mitigates that just as well.
Barring a user using 1Password and still reusing the same password on every site (why are you using 1Password then?) the only use-case I can think of for storing TOTP tokens alongside your password in 1Password is "the service requires me to use TOTP and I don't care about security".
That said, full disclosure, I've kinda got a bone to pick here because I was a long time 1Password user that was forced to switch off when 1Password removed the ability to have multiple vaults because, as they have said on their support forums, "It's called 1Password and our users only want one password." which was a... mind-boggling response from a company that should be focused on security. And this blog post really doesn't instill much more confidence than that response did.
These days I have my passwords in a KeePassX database. I have my TOTP secrets stored in two places--on my phone in an authenticator app where they're on a very secure platform and practically unrecoverable, and in an entirely separate KeePassX database that has nothing in common with my password database. The only time the KeePassX TOTP database is opened is when I set up a new service and want to add my TOTP secret. It's only there to "break glass in case of emergency" and allow me to recover access if my phone were to become unavailable. It's the right balance of risk _for me_, and in most practical sense two _factor_ authentication.
When did they remove the ability to have multiple vaults? I'm assuming this is really recent as I'm currently using it with 2 accounts and each has 5 or 6 vaults in it.
Unless they added it back in, you have 5 or 6 "vaults" that all open with a single password?
For a single user, they're equivalent in almost every way to just having 5 or 6 folders in one vault, so the "separate vault" distinction is pretty much gone.
Basically, what I want is two separate, independent bank vaults. Opening one should not, in any way, help you open the other. I want to keep my spending money in the main vault, and my stack of gold bars in the other vault that I only open in case of an emergency. That way, the risk of anyone seeing the combination over my shoulder or sneaking in when I've got the vaults open is minimized.
What 1Password gives you is the ability to easily create other vaults, but every time you build a new vault, they put the combination for that vault on a sticky note inside your first vault and give you no way to remove it. The security of your second, third, fourth, etc vaults is irrevocably linked to that of your first vault. All your gold bars are, no matter what you do, forced to always be exactly as secure as your spending money because as soon as someone gets into your spending money they just need to look at your sticky notes and they've got access to everything else.
There's no real security purpose for having a second vault in this system. The only purpose is to more selectively control access to what other people can access (i.e., vault sharing / team features). If you want to make some of your spending money available to your wife but not all of it and not your gold bars, you can build _another_ vault, put some cash in it (and the sticky note in your first vault so you remember how to get in!) and then also give her a sticky note she can stick in her vault with the same combination. Now you can both easily access the shared vault, but she can't access your main vault or your gold bars and you have no way to know what she has in her vault at all.
Things like this and the enforced cloud sync are decisions that weren't in any way a trade-off (the path they chose does not preclude the more secure path). The fact that they keep removing the more secure option regardless really seems like a security company that's more focused on market and revenue growth than security now.
If your use-case aligns with what 1Password is selling, I'm sure they still make a great product.
If sharing's a huge part of what you're looking for, then 1Password or Bitwarden are probably your best options. If it's not and you're comfortable managing your own sync, then I don't think KeepassXC can be beat.
Pretty much the only thing I'll say concretely is Don't. Use. Lastpass. Like, if you've got the option of putting all your passwords in a plain text file on your desktop or in LastPass... pick the plain text file.
Yeah I view different vaults as a way to selectively share access and somewhat organization as opposed to 2 different independent password stores. I can understand the need for your use case and it makes sense. I think the only way to do that with 1Password now would be multiple accounts which makes no sense from a user perspective. It would be nice if they went back to supporting your use case as well.
> ... but the real-world value here is overstated. Malware can always just steal your tokens.
Stealing a TOTP secret means being able to generate all the tokens. Which allows, for example, to take over an user account and lock the legitimate user out of his account. MITMing a single U2F/FIDO2 allows you to... log in? From one of the system uses to access his account (the one that's compromised).
I've got sites where the FIDO2 to log in and the one to change any security setting require two different security keys. And even when it only requires one security key, the procedure to take over an account requires several tap on the physical security key. A savvy user won't be tricked into tapping his security key for no reason.
Let's take, say, a brokerage account. There's a security key for withdrawals. Without that security key an attacker would be MITMing me by stealing one token could... Consult, what, see my balance and trade for me!? But he still wouldn't be able to steal a cent (and my account ain't big enough to move the market).
The real-world value of an HSM sitting on a device with a tiny attack surface has a lot of value.
The very reason they exist being that compromised computers are a thing. Compromised Yubikeys are not.
> MITMing a single U2F/FIDO2 allows you to... log in?
You mean token theft? Most sites let you add factors without step-up auth once you're logged in [1]. That's what attackers prefer to do, vs. locking users out, which just gives away the game.
To be clear, end-running around hardware keys with stolen tokens isn't hypothetical. See for example the fallout from the last Okta breach at Cloudflare: https://blog.cloudflare.com/thanksgiving-2023-security-incid.... I make my team use YubiKeys, but there's no upside to being naive about what they are and aren't good for.
Anyway the kinds of sites you're describing are vanishingly few. What people mostly have to deal with are sites like Fidelity's. If you want something other than SMS or push notifications, you have to call Fidelity on the phone, and then all you get is Symantec's bloated wrapper around TOTP.
It helps but isn't perfect. The attacker can't just pick up the secret. With a passkey they would need to trick you into touching it to authenticate them. Probably by timing it when you think you are about to do a regular authentication.
Passkeys are the software version ('platform authenticator') of hardware keys ('roaming authenticator'), so no touching. Biometrics in this case are an attempt in software at something like the user presence test hardware has, but this is an OS-level guard, so the guarantees are much weaker. (Of course you can also have a biometric lock on a hardware key, which would be an improvement under the physical access threat model.)
> For the majority of people, storing TOTP in 1Password is well within their risk tolerance. There will always be those of you who will trade that convenience because you want or require the added protection of true 2FA. And to those faithful hardware key crew members: Think of your true second factor as less “extra layer of security,” and more granular protection that will apply only if you’re subject to certain forms of attack.
this is the crux really. Especially when a web based password manager is in use [0], this is not at all within risk tolerance for people really striving for a long-term threat model which they do not need to revisit every couple of years.
Buying multiple hardware tokens and keeping one authenticator/TOTP app on phone is very practical the best you can do and it is secure, loss-proof and will last for a long time. Most services allow you to add multiple types of 2FA devices.
Multifactor Authentication is having at least two of the following:
* Something you know (such as a password)
* Something you have (security key, TOTP generator)
* Someone you are (biometrics, fingerprint/face id)
* Somewhere you are (network or geolocation)
Using a password manager app and TOTP generator app on the same phone is clearly a single point of failure and does not add meaningfully to your security compared to just storing the TOTP in the password manager. If your device is compromised the attacker has control of both apps potentially, and very likely the TOTP app does not require an additional password or factor. And unless you use a FIDO2 device for MFA, TOTP is not phishing resistant. You can mitigate these issues though.
However, if you require a specific device to access the password manager by one of the following methods:
* Offline password manager such as KeepassXC (needing the password database file)
* Needing a keyfile (like with KeepassXC or 1Password’s device key)
* Needing to be on a specific network such as VPN (when using a self-hosted password manager like Bitwarden and configuring the firewall to be limited to a wireguard network for example)
Does this count as an additional possession factor or location factor? And if it counts as a possession factor does it meaningfully increase your security posture to have multiple possession factors beyond a FIDO2 key?
> Using a password manager app and TOTP generator app on the same phone is clearly a single point of failure and does not add meaningfully to your security compared to just storing the TOTP in the password manager.
You are so wrong. You can log into a password manager from the browser. Now you’re completely pwned.
Let’s compare it to separated 2FA: they pwn my 1Password, but then how the hell are they going to log into my 2FA app? They’d need to breach the 2FA on my Apple/Google account and then again on my Authy, which in practice will mean either a SIM swap or SS7 attack. Only adept threat actors have access to those techniques.
If you just have a pedestrian threat model, store your unimportant 2FA in your password manager, and the really important one’s in a separate 2FA app (2FAS or Authy). 1Password is naturally 2FA by way of its Secret Key system.
> You can log into a password manager from the browser. Now you’re completely pwned.
Can you elaborate here?
My point was that your phone is a single point of failure if you use it primarily for both your 1password account and your TOTP generator. Compromising the phone gives you access to both apps. And I mention that this can still be mitigated. One of those ways is through adding a password or biometric unlock to your TOTP generator app (as you point out). Or you use a second device like a yubikey. But the point of that paragraph is that combining passwords and totp codes into your password manager is a single point of failure. Separating the passwords and totp but still using just 1 device, can also be a single point of failure.
>> You can log into a password manager from the browser. Now you’re completely pwned.
> Can you elaborate here?
Your point is that if you have both a password manager and a 2FA app, it is functionally as insecure as just having a password manager with integrator 2FA storage. I pointed out how that is worlds apart. If you store your passwords and TOTP together in a password manager, and someone breaches it by say, shoulder peeping, they can just login via the web and now they have full access.
In the case of a separate 2FA app, no such luck for them. They can log in to your password manager, but since they don't have access to your TOTPs, they can't login anywhere (or anywhere important, if you do what I do). This means they can't breach your Apple/Google account or 2FA either.
> Separating the passwords and totp but still using just 1 device, can also be a single point of failure.
But if someone compromises your phone, they are already physically close. At that point can also just yoink your Yubikey out of your bag or pocket, both within less then a meter of your phone :)
In general, theorizing about evil maid attacks is useless because any sufficiently motivated threat actor with access to you and your stuff will breach no matter what, and your unfriendly neighborhood hacker will not have sufficient motivation and/or tech to breach you.
If you mean that as: if your drop your phone in a lake on vacation you're SoL.. well, keep a sheet of backup codes printed and hidden or in a vault and bring it with you on vacation. The backup codes aren't enough for any opportunistic thief, as they'd still need your password and/or access to your e-mail.
> They can log in to your password manager, but since they don't have access to your TOTPs, they can't login anywhere (or anywhere important, if you do what I do). This means they can't breach your Apple/Google account or 2FA either.
This is wrong. TOTP apps like Authy have no authentication. Open the app and the codes are just there, visible to anyone without having unlock it.
If they login to your password manager in a remote location, from their own device, they can't get to your TOTPs if you store them separately in an app on your phone.
> TOTP apps like Authy have no authentication.
This is just wrong. My Authy is locked with separate pincode+FaceID and has been for years.
And in general, if they are in your physical phone (presumably because they know your pincode), they can wreak all sorts of havoc already. They can add themselves as an alternative recovery e-mail to your Apple ID / Google account. Perhaps they can even disable TOTP 2FA via SMS, although I am not to certain of that.
Everyone is talking about threat models but like the actual use case here is some web service that doesn’t matter very much that you use sometimes and if it was compromised that wouldn’t matter either but they make you use some fucking login scheme that adds extra time to your day. Or even more accurately they insist on you using their own proprietary mobile app to get a code which really only exists to track you and make trouble when you log in from a different city or have a VA log in for you, spawning a call from them to try to insist on you buying extra licenses so you find the fine print link that lets you use a TOTP instead and get a few minutes of your life back every time as well as their useless fucking app off your iPhone.
As is often the case in this discussion, the die hard security people will quote the definition of “true” multi-factor with the standard “at least two of something you ____”, but this level of security isn’t needed for most sites.
I find it helpful to think of most “2-step” logins as simply an extension of passwords (one-factor), plus an admission that both users and web sites/apps are completely incapable of following the rules of password management. Users can’t stop reusing passwords, and web sites can’t properly store them and avoid getting hacked.
2 step logins are a method to force users to use a password that changes every 30 seconds, and that password is unique per web site/app. It shouldn’t be seen as a true multi-factor in the traditional sense.
That's not correct, at least depending on your threat model. Having a password stored + totp in a password manager does give the advantage of protecting you against the loss of the stored password itself.
Specifically with 1password I have all three factors you've mentioned above. 1) knowledge - my vault password is memorized, 2) inherence (?) - biometrics used to unlock the vault on trusted devices, 3) possession - my account requires a security key to unlock.
Having a password stored + totp in a password manager does give the advantage of protecting you against the loss of the stored password itself.
Which becomes far less relevant when using a password manager, because people don't reuse passwords anymore. Password managers also autofill, so eavesdropping on a password is also not possible anymore. One of the primary vectors for compromising passwords is compromising the password manager, which would also compromise the TOTP codes if they were in the password manager. You have much stronger protection against that if your TOTP codes are stored on a separate device.
That said, TOTP is also pretty terrible because does not really protect against phishing (just make a phishing site proxy both credentials).
Hardware keys are the only really secure solution if you consider password manager compromise as part of your threat model.
Remember that password managers are comprisable, just look at LassPass' history.
If your 1password is compromised, then loss of the password would mean loss of the TOTP, in which case TOTP doesn't help.
But there are other scenarios where your password could be stolen without someone getting access to your 1password, for instance if your connection isn't protected and a man in the middle can intercept your password.
In the end, I would argue that having TOTP in the same place as your password is weaker than having it somewhere else, but it's still better than no 2FA
Another one would be a password change attack. TOTP in 1pw protects you against almost all of the things TOTP normally would, except an attacker somehow gaining access to your vault. But in order to gain access to your vault, they would almost certainly need access to one of your unlocked devices, thanks to the 1pw secret key, which is required in addition to your master pw to unlock the vault on a new device. And if they have that, thrn they would have your second factor even if it were in a separate app.
But there are other scenarios where your password could be stolen without someone getting access to your 1password, for instance if your connection isn't protected and a man in the middle can intercept your password.
Then they could also intercept your TOTP code, which is valid for a pretty long time by default (remember that the TOTP code is accepted for some time after the counter goes to 0 to account for transmission delays, slightly out of sync clocks, etc.) and use that to log into your account.
TOTP does not protect against modern forms of phishing. You need something like FIDO2.
That's a very valid point, as an automated attack could then be performed. I guess it would at least help against an attacker that would be manually checking what's inside the packets captured, or that would let his attack passively capture everything for a while and then proceed to attack.
That doesn't mean they have access to my TOTP for the service, even if it's managed by the 1P app.
Loss of 1P's password/key would indeed also mean loss of my TOTP. But then one would have much bigger problems anyway, except if all their 1P passwords also had an external TOTP.
- Eavesdropping on you, doesn't happen because you use the password manager's autofill.
- Hacking service X, TOTP doesn't matter. They'll have the TOTP shared secret, but who cares anyway, they have access to your whole account.
- Using the same password across sites -> shouldn't happen either, this is why you are using a password manager.
- Phishing: while they cannot access your TOTP secret, they can just ask you a TOTP code while phishing as well and log onto your account.
So what is this scenario where an attacker knows your password, needs your TOTP, but doesn't have it? The primary scenario I can think of is where they somehow compromised your password manager, but you stored your TOTP secrets on a separate, uncompromised device (like your phone).
>- Eavesdropping on you, doesn't happen because you use the password manager's autofill
Not necessarily always, I could also copy paste from the password manager (e.g. for some app that doesn't support the autofill), write it from memory at some point, and so on.
Password manager just means "place to store passwords safely", it doesn't mandate the passwords are generated by it, that autofill and browser extensions are used, and so on.
>- Hacking service X, TOTP doesn't matter. They'll have the TOTP shared secret, but who cares anyway, they have access to your whole account.
They can (and often do) hack and get the passwords, but not at the same time have access to the account data. E.g. just hack the auth, or have the password file/db leak, etc.
>- Using the same password across sites -> shouldn't happen either, this is why you are using a password manager.
Doesn't matter, can still happen anyway. Not all passwords were created with the password manager, and some someone might not have bothered to change once he added them there.
>- Phishing: while they cannot access your TOTP secret, they can just ask you a TOTP code while phishing as well and log onto your account.
That's still about them not having and needing your TOTP.
>So what is this scenario where an attacker knows your password, needs your TOTP, but doesn't have it?
For starters, the case where they "ask you a TOTP code while phishing" and you don't give it to them.
It's not mandatory that you're prone to their phishing.
> - Eavesdropping on you, doesn't happen because you use the password manager's autofill.
I rate this more likely and it’s one reason I still use TOTP stored in the same place as the password for other services.
A lot of sites are susceptible to cdn JavaScript compromises, and at least with TOTP stored in the same place as the password, a password replay attack has a very tight window of usability
I don't see those as realistic. Session interception largely isn't a thing anymore, unless we're talking about nation-state levels of attackers, and if the service is storing your password unhashed then I sincerely doubt their 2FA is configured in a secure way anyway.
I think it’s not a nation state actor thing. In 2018 British airways checkout got popped by a JavaScript being library being changed to eavesdrop credit cards. The same thing could easily happen with password forms
Granted they didn’t break the session in flight, but there is a low bar to achieve the same thing
if your network is compromised I can read your password but not totp
if I hacked a website you’re registered to and you had reused your password I got your password but not totp
if I broke through your computer and password manager then yes it’s all over, but this is not the only threat model and frankly the least i am worried about
> if your network is compromised I can read your password but not totp
What part of my network? The password is being encrypted in my browser, sent over an encrypted and authenticated connection, and decrypted by the service I’m logging in to.
The only real place to compromise here is before the “browser sends this to SSL library” part in which case you’re already on my local machine and you can just grab everything in my password manager when I unlock it.
> if I hacked a website you’re registered to and you had reused your password I got your password but not totp
If you’re not using a password manager and a different password for each service, then yes, using TOTP provides a large security benefit.
If you’re using a password manager it is probably specifically to avoid password re-use, so this doesn’t apply in most cases.
> if I broke through your computer and password manager then yes it’s all over, but this is not the only threat model and frankly the least i am worried about
If you’re on my computer, yeah, you’ve got both and the TOTP, they do nothing.
So there’s no scenario here where “password manager for passwords + TOTP” is decreasing my risks in any meaningful way.
Say, I want to go the extra mile of not storing them together. What would I have to do?
- Both in same password manager is obviously storing together.
- Both on same phone, but different apps. There are the subvariants of: password manager and dedicated OTP app or two different password managers. Also there is the consideration where the apps really store the secret data, e.g. system provided vault
- OTP on a separate device
I think the middle option has too many ifs and buts and you could argue that as long as its the same device it's not really separate.
So dedicated OTP token. What should I use?
Cheap mobile phone? Does it need a SIM? Are there dedicated devices? Can they store multiple keys?
How do these hardware devices pair. They probably can't read the QR code provided? They also seem to have just one button, so I need one device per account?
EDIT: I see the last link has a multi account device and some devices have USB. How does it work, when it says "factory programmed"? I've never seen that I can sync an app to an existing token.
Factory-programmed ones are for systems supporting secret key import, i.e. Microsoft Entra ID . It is not for replacing your Authenticator apps (although based on the same algorithm, TOTP).
I feel like the security benefit of using FIDO2 isn't really there, since I don't remember when I've actually set up WebAuthn as my two-factor without being prompted to have another mechanism like OTP or SMS as a backup solution. Not that many sites even support it in the first place though.
There are systems supporting WebAuthn as the primary method, such as Gmail or M365. The systems requiring OTP or SMS as a backup are just examples of bad security design. Still, even if you have OTP as a backup, and FIDO2 as primary - it reduced phishing attack surface to a certain extent
To expand on that (for those who might not know), the actual secrets are physically on the Yubikey and the Authenticator app on iOS or Android is using them to generate the One-Time Password.
This means you can also roam those secrets to different devices (as they are on the Yubikey). But it also means that you need to have access to the key whenever you need the OTP!
One caveat is that you can "only" have 32 or 64 accounts per Yubikey (number depending on the version of the key)
How much we care about trying as users to keep our accounts secure, the websites aren’t that good to keep our data secure. How many data breaches we had in last 5 years that affected all of us. I feel like at least a few affected me.
So in that case storing OTP with passwords or don’t does not matter.
1. Credential phishing. Where you store your TOTP secret doesn't matter.
2. OAuth phishing. Where you store your TOTP secret doesn't matter. (This also runs right through FIDO and has been growing in popularity for about a decade now: https://www.trendmicro.com/en_us/research/17/d/pawn-storm-ab...)
3. Data breaches. Where you store your TOTP secret doesn't matter unless your password manager backs up online, that's what gets breached, and the data isn't properly encrypted. Which has happened.
4. Malware. Where you store your TOTP secret matters. This is why U2F and FIDO2 have a user presence test, but the real-world value here is overstated. Malware can always just steal your tokens.
5. Physical access. Where you store your TOTP secret matters. If you care about security though you'll have other measures in place to keep someone with physical access out, which is enough against basically anyone except governments.
Summary: A "true" second factor doesn't really matter. What matters is deciding which scenarios you care about and making sure you have security you'll actually use given those constraints.