You may remember that a few years ago I wrote a post when LastPass introduced “cloud backups” for 2FA authentication tokens. At the time I did say that I wouldn’t want to go ahead and move my important logins to store the second factor in the same password manager as the first, as that would just negate the main point of 2FA.
Recently I managed to elaborate on Twitter thanks to Corey mentioning password managers and the use of MFA codes. Twitter being twitter, both Corey’s point and my elaboration have been pretty short and I think it’s worth looking at this in a longer format to make sure that we don’t actually keep taking security as a collection of axioms but we challenge the reason why we do certain things in a certain way.
First of all, what are we talking about? Password managers are software and services that will store passwords, hopefully unique across services, behind a single “master key” of some kind — usually a passphrase. Pragmatically speaking, we could consider password booklets a password manager as well, but then the discussion we’re about to have is going to be a lot more complicated, so let’s not do that.
Also as an aside, the password booklets that so many people make fun of are actually a great idea for less technologically savvy users — it’s definitely safer to have a physical book with a number of different password for each service written down and stored in a relatively safe place such as a desk drawer or the small safe on the bookcase than having the same password on every service. Yes, it would mean that if someone stole your physical booklet they would have access to all your passwords… but so they would if it turns out your password is your pet’s name followed by your wedding anniversary!
Back to the software/services that store your unique passwords. As it turns out, password managers got more complicated over the years, so I stopped using sgeps in favour of LastPass first, and 1Password more recently. In addition to the whole point of syncing, the integration with browsers and mobile operating systems, while creating additional risk (as Tavis would immediately point out) also helps protecting against phishing, as the auto-fill support would only fill in the password that is connected for the currently-browsed website.
And one of the other complication that password managers have been adding to their software over the past few years is the ability to use them as TOTP authenticators. This is relatively easy because what TOTP needs as input is just a shared key, the second input is time itself. So the authenticator just needs a way to read that key off the QR code, know the current time, and generate the right TOTP at the right time. Easy! Except that now you’re placing the password (conventionally “something you know”) and the second factor (conventionally “something you have”) in the same place. And that has people frown up, sometimes for good, and sometimes for not so good reasons.
So let’s go back for a moment on what TOTP is good for. Generally speaking, the idea is that you want to be able to stop a malicious actor from accessing your account if they get access to your password — and this is where the whole frowning comes to be, when storing the TOTP key together with the password. It’s like having two locks with different keys, but keeping the keys always on the same ring: if they steal your keyring, they get both keys and the second lock didn’t help you at all!
But sometimes the problem is not that someone took your keyring, but something more subtle. It may be that someone took a picture of one of your keys, and now they can make a copy. Or it might be that the contractor who set up the apartment building you live in has cut corners, and installed locks in sequential series, and the keys are for sale easily. Or maybe the cylinder is extremely easy to unlock. In all these cases, having two different keys, even though stored in the same place, does have an advantage. Though let’s be honest: physical key metaphors only get us so far, given that the standard in London at least is to provide two locks but with the same key.
So let’s try to figure out what we can defend against, with the help of TOTP as 2FA. The first obvious thing is to provide some level of protection against password reuse: even if your password is the same across separate services, the shared key won’t be, as it’s provided by the service itself. Which means accounts protected by 2FA are not subject to password stuffing. But this should not apply to users of password managers, as having unique passwords across services means no two services have the same password, and thus stuffing is not a concern.
There is a suggestion at times that TOTP can alleviate phishing risks, but I find this argument very tenuous. It’s a similar security theatre suggestion as the banks that only ask you three characters out of your password: it only works against phishing that does not try to use the credentials interactively, which is the laziest option. Indeed, in 2021 we should assume that there’s no latency between your password being phished, and being used to access your account. Which means any 2FA that relies on you providing information to the phisher (TOTP, HOTP, Yubikey, password cards, …) is no defense at all against phishing. This is why U2F is better than OTP: U2F (and I guess Webauthn that is the standardised implementation) is tied directly to the domain that is requesting the authentication, so it cannot be phished. As it turns out, TOTP in password managers has similar level of protections, since logins and identities only auto-fill on the recognized domains.
Where things start getting hard for password managers as sources of truth of TOTP keys is in regards to compromise defense: whether it is local (malware) or remote (service-level compromise, either because the code pushed to clients is compromised, or the service is not actually fulfilling the promise of encrypting the users’ vaults and be unable to read them), if you are storing the password and the key in the same password manager, the 2FA is no defense whatsoever. So in that regard, using two different services for storing passwords and TOTP does make sense, particularly if the TOTP keys are only accessible from a separate device that has stronger defenses against malware — the fact that the TOTP value is usually a short number that’s easy to type makes it possible.
The last salvo, of where TOTP keys in password managers still make a bit of sense, is when using untrusted devices. While a compromised system that can successfully phish you into providing password and 2FA is fundamentally a “game over” scenario, there’s a narrow case in which an untrusted device is being keylogged with a non-realtime implant — if that’s the case, exposing the password but not the TOTP key does significantly reduce the risk of an account takeover.
All of that is a lot of words to state that, while the ideal solution in my opinion is U2F/Webauthn, there is a very tiny advantage in using TOTP keys stored in password managers, when compared to no 2FA at all. It would be better, from the point of view of security, to not store the TOTP key in the same manager as the password, obviously, but that comes with compromises: either you don’t backup your keys at all, in which case if you lose the one device that has them, you’re in trouble, or you use a separate service for storing them, which might not provide you with any protection against phishing.
If your threat model does not include compromised client devices and password manager services, it might just be easier to accept to not turn on 2FA. If the password is leaked due to a compromise of the upstream service, then the likeliness is that the TOTP key would be just as compromised anyway (remember: it’s a shared key!) So, what’s the value proposition for TOTP keys stored password managers, in such a case? Well, in my experience it comes from services enforcing 2FA for all, or most, accounts. It’s very hard for the operators of a service to know whether you’re using the same complex password for multiple services, or if you are using a password manager. Yes, they can integrate pwned passwords to not let you use a password that is likely ready to be stuffed, but maybe your l33t5p34k seemingly-complex password is shared between your email account, Kickstarter, Facebook, and PayPal! So instead, they can restrict all of the users that do not have 2FA enabled — and you can easily enable yours with no friction by using the password manager you already have set up.
Now there is one obvious alternative that I have avoided talking about up to now: push verifications, also often referred to as login approvals. This is something I’m particularly fond of, because I have tested it out back in 2012 thanks to Duo (and particularly, Dug Song who commented on one of my previous posts.) I like these, because they can, in theory, be used to provide the users with more information about where the login is happening. Unfortunately, this usually just ends up being messy GeoIP, which end up just confusing most ordinary users. So while they could in theory provide some level of protection against phishing, this is even less reliable than the password managers themselves, and pretty much non existent compared to U2F/Webauthn.
Similarly, the option of receiving SMS for login codes is something I have stated out right that is not worth implementing in 2021. Not only it doesn’t move the needle at all in terms of protecting against phishing, but it ends up being costly for the services implementing it (sending SMS may be cheap nowadays, but not free!) as well as vulnerable to compromises of a third party account (the phone provider.)
So there, I think this covers all of my thoughts. If an account is not important enough to bother getting out your phone to pass 2FA, and they don’t have U2F as an option, then go ahead and use the password manager. It’s literally better than nothing. And if you’re implementing a 2FA flow and you still want to include TOTP (rather than just Webauthn), don’t break password managers — the same way you shouldn’t break auto-filling and pasting.