1

It's no secret that many popular password managers (1Password, Dashlane, LastPass, KeePass, and many others) support some form of two-factor authentication. This is often implemented via TOTP or other systems, but it could very well also be U2F-based or similar.

However, TOTP-based two-factor algorithms don't store a secret in their digits, neither does U2F provide the ability to encode a secret in its response.

Given this, this leads me to one of the following assumptions:

  • The password manager server will refuse to send you your (encrypted) vault unless you present 2FA credentials,
  • Or your password vault has multiple keys, one of which is stored (I'd assume visible to a theoretical rogue employee) on the server and sent down after a 2FA challenge is passed.

Assuming the above is correct, the "second factor" would only be protecting something static: either a static encryption key sent by the server, or the encrypted vault itself. In theory, a rogue employee of a cloud-based password manager would then be able to use their access to either get my vault or one part of my vault's encryption key.

Similarly, non-cloud password managers (such as KeePass) would have the same issue. The 2FA section would only be a measure implemented in code (and, assuming an attacker has enough access, something they'd be able to patch out).

So, unless I've missed something critical here, what real security benefit does 2FA provide on a password vault? How would 2FA realistically protect me against a stolen vault file more than just a strong password?

  • Keepass does not support TOTP. It's not in the application's treat model (as it uses a local DB, OTP cannot be used to protect against brute-force attack against weak passwords). – Stephane May 6 at 6:13
  • 1
    KeepassXC (community-driven advancement of the abandoned KeePassX) does support TOTP as of v2.2.0: news.ycombinator.com/item?id=14633576 – SeeYouInDisneyland May 6 at 6:50
  • 2
    You're confusiong two different things: KeepassXC (or Keepass with the TOTP pluging) acts as TOTP source (for storing TOTP secrets). The TOTP is not used to unlock the database in any way as you describe it. – Stephane May 6 at 12:15
-1

Online password managers go through a huge amount of effort to not know your master password. It will never be sent to the service. Online password managers that have a web login will have JavaScript that performs cryptographic operations on your master password before sending the hashed master password to the server. This means that there is no chance for an employee to steal your master password as it is never put on the wire.

At least for the network based password managers, the 2FA protects against a network attack, preventing an attacker getting access to your encrypted vault. Just knowing your master password (which may or may not be the encryption key, depending on the password manager) will be insufficient to motivate the server to transmit the vault. This corresponds to:

  • The password manager server will refuse to send you your (encrypted) vault unless you present 2FA credentials,

from your question.

Regarding,

  • Or your password vault has multiple keys, one of which is stored (I'd assume visible to a theoretical rogue employee) on the server and sent down after a 2FA challenge is passed.

That is not done.

  • You've got a grave mixup in the above - the hashed-password is not what's sent to the server - i.e. for crypto when we say hashed it's safe to assume we mean the one-way-function type - which would be useless in a password safe! The point is to be able to retrieve the secret - not to check for a match the way hashes are used in password logons. It's ciphertext that they're storing, not hashes. – pacifist May 6 at 12:23
  • 1
    Your master password is hashed before being sent to the server, @pacifist. Hence your master password. It will never be sent to the service. See support.logmeininc.com/lastpass. I understand that encrypted passwords are sent to the server, but I never mention them in the answer. I went through and added the word master in a few more cases to clarify. – Neil Smithline May 6 at 14:32
  • but surely you see how disingenuous that is... People for real need to downvote this answer. the master password never needs to be sent to them for the secrets to be at risk when you expose it to code running on your side sent from them!... Your 'master' password is just as at risk of later-updated code from them stealing it from you when ran, and being sent god-knows where. The statement 'it will never be sent to the service' is how its meant to work if not being evil, but surely you can see that's a promise based on trust... the code can do whatever if compromised. – pacifist Jun 8 at 4:52
  • eh, I posted it edit that rewrites the answer to be correct ¯_(ツ)_/¯ guess it doesn't need be downvoted as much for the correct version – pacifist Jun 8 at 5:11
1

2FA will protect you against 2 attacks: keyloggers and shoulder-surfing.

If someone watches you typing your master password, or a keylogger captures it, the window of opportunity for dumping all your passwords is small. For shoulder surfing, the attacker would need to memorize your password, the 2FA code, login on another computer, and input your credentials before the code expires.

If your cloud password storage does not allow two logins to use the same 2FA code, an attacker will not be able to login even if they capture both your password AND 2FA code and manages to login before the code expires.

You are not protecting the password against the cloud provider, they have a reputation to care about, and their reputation is way more valuable to them than any password you may have. You are protecting it against attacker close to you.

  • 1
    In theory though, if an attacker can install a keylogger on my system, wouldn't they be able to exfiltrate my encrypted password file as well and then break it at their own leisure (or with the keylogged password)? I get that 2FA would protect someone from logging in to my password manager account, but how would 2FA protect a stolen vault (especially for KeePass)? – Kaz Wolfe May 10 at 15:34
  • 1
    The main reason to use a password manager is not to protect against something on your computer, but to protect your password when the site you have an account gets hacked and its credentials end up on Pastebin. With a password manager, only that credential is lost. Without it, you probably have one single password, and all your services are compromised. – ThoriumBR May 10 at 20:32
  • 1
    But if we consider that a "keylogger" means "malicious code running on your machine" in the first place, then malicious code could just dump all the passwords (it has access to 2FA because it runs on your machine) and then call home. Then 2FA only protects you from shoulder surfing and a few other possible attacks (finding passwords in some log, on old disks, by recording the noise of your keystrokes, etc.) – reed Jun 4 at 15:17
  • 1
    If your machine is compromised, nothing will save you. It can not only dump all passwords from your password manager, but it can also steal every and any information on your computer, can even impersonate TLS-protected sites. – ThoriumBR Jun 4 at 15:29
1

assuming we're talking about a true cloud-based platform, you can't protect from the sum combination of the access employees have as a group - at some level you need to place your trust in the sum of them since across employees they would have enough permission to MitM your sessions anyway & steal secrets at a later point (even if the master password/encryption keys are kept on your side now - at a later point the code your run from them that you expose those keys to could have updates to also be stealing the keys - you trust your keys to that code.. and they control it... the only guarantee you have that the code won't do that in future is their promise, and ideally them going to effort to compartmentalise what it takes for them to be compromised like that so it needs to be more than one employee).

The hope is that they compartmentalise trust in a way where it takes multiple bad actors for something bad to happen.

on the benefit of MFA: What MFA is protecting against though is a whole bunch of threats primarily to your endpoint, including things like shoulder-surfing. Typically these are frankly the bigger threat than a multiple-rogue-employees-targetting-you scenario.

I got downvoted on something where I think my answer ads significant content over what's above: Even if secrets are encrypted in a way where the decryption is done locally on your machine, if you rely on code coming from the cloud-based password-safe provider, they can steal your passwords.

If they were to go rogue they could supply altered code for how the decryption works, in a way where even with decryption using a key you only have on your computer, used to only decrypt the secrets once sent to your device from encrypted cloud-storage, the rogue code in the web-page/plugin that's used as the algorithm for decryption could include javascript/other code to send the secrets back to malicious infrastructure - the security model is only as safe as the total sum of failures it takes (if properly compartmentalised, multiple rogue employees) for your secrets to be stolen in this manner.

  • You can protect against employees by ensuring that passwords are never sent to the server unless they are encrypted. Add to that strong development-->deployment processes to ensure that employees don't deploy rogue code, and you have a very secure system. – Neil Smithline May 6 at 9:56
  • 1
    I think you've misunderstood badly. Even if everything is done client-side, its done by encryption code provided by the company, operating on ciphertext stored by them. You can't hide from the fact that if they're providing the code to unlock it, if they were to 'go evil', that code could be easily altered to also be sending plaintext secrets back to them. Your 'development->deployment processes' is exactly what I said about compartmentalising trust!.. exactly my point. Ideally it at least needs multiple failures. Your comment added nothing I didn't cover. – pacifist May 6 at 12:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.