So, with most password managers, when you authenticate on a new device, you are prompted for MFA.
The user had a keylogger installed on their machine, so the attacker could collect the master password, but how did they login to the vault on a new machine without MFA?
Did they get the MFA seed and login on a different machine, and nobody received a "You're using LastPass on a new machine, if this wasn't you..." message?
Did they exfil all that data to the compromised machine first, then out?
Unless I'm missing something, this doesn't seem right.
They had code execution on the persons computer, the encrypted vault is downloaded and stored/cached on the computer - you only need the master password at that point to decrypt it. Or to read the decrypted version out of the process (e.g. your web browsers memory)
The 2FA part in the password managers (and least in the major players currently) is to get a copy of the encrypted vault from the server. The user did that part, and the encrypted vault was not easily accessible locally.
Sure, but I wouldn't expect the vault to be accessible without 2FA each time it is cached. 2FA should be used as part of the decryption process even if the vault is cached.
You expect 2FA to be used for decryption? I'm not aware of any system with that does that that has any significant amount of usage.
Even if the 2FA was used for decryption, it wouldn't really make you much safer, because malware can steal the decrypted vault out of memory right after you type in the 2FA. A HSM would solve this, as long as the HSM has some out of band way to communicate with the user, such as an approval button that malware can't press and a screen saying what password to release.
> Even if the 2FA was used for decryption, it wouldn't really make you much safer
If the second factor is stripped for some arbitrary time, you don't have 2FA anymore. Your argument that "any adversary can read the vault from memory" is a weak one, we might as well not have passwords with that attitude.
The point of a second factor is that BOTH need to be present to get to the secrets. If one of those factors is stripped away for "convenience" we're misunderstanding the point of 2FA entirely. I can't make this any clearer.
>Your argument that "any adversary can read the vault from memory" is a weak one, we might as well not have passwords with that attitude.
It all comes down to threat model. If you don't have malware on your machine, 2FA and passwords are quite useful. If you do have malware on your machine, they're basically useless. This is basically the same for any service. Name one website or program that's safe even if you have malware on your machine.
>If one of those factors is stripped away for "convenience" we're misunderstanding the point of 2FA entirely. I can't make this any clearer.
It's not for convenience. It's because there's no practical way to implement encryption/decryption with 2FA. You seem to think there's some practical way to do it, but there isn't.
Lastpass 2FA protects against the threat model of an attacker who has stolen your password. In that case, the attacker cannot steal the contents of your database because the attacker can't get any form of the database, encrypted or decrypted due to not having the 2FA. Unfortunately now that an attacker has stolen all the encrypted databases by compromising Lastpass itself, this threat model is no longer realistic against this one specific attacker or any attackers that this attacker shares the loot with, because they now all have your encrypted database.
> You seem to think there's some practical way to do it, but there isn't.
It is an implementation detail of the password manager itself. Any password manager can update their implementation to ensure the second factor is always needed when decrypting the vault. I'm not sure why you think this is an impossible feat. It's a choice that can be made.
How? What type of 2FA are you talking about? Is there any that does this that many people use?
The only thing I know that does encryption with 2FA is https://keepass.info/plugins.html#otpkeyprov . But I highly doubt it has much usage. It's going to be annoying typing in a 2FA every time you decrypt your password database (I decrypt my password database maybe 10 times per day). More concerningly, if you press the button on your 2FA device (this is HOTP, which requires you to press a button to get a new code) too many times, or typo the 2FA too many times, you can permanently lose access to your database because the HOTP device will advance past the point that the database supports.
So yes, it's a choice that can be made, but it has very major downsides.
Read the technical details of TOTP, at root, you and the other end are performing similar mathematical operations on a shared secret such that knowledge of a single result gives you no information about later results. The actual check is just a string compare; the result is not included in the vault decryption operations in any way. Thus, if you have root, you can just alter the Check2FA() function to return true. I'm not aware of any encryption algorithm that can include rotating 2FA data in the actual decryption process.
There's a keypass plugin that allows you to encrypt and decrypt your database with HOTP. I doubt it has much usage. It seems really inconvenient, and also potentially dangerous, because if your HOTP provider gets too far ahead of your database (you press the button too many times, or typo too many times), you permanently lose access to your data. You would want a HOTP provider that supports rewinding to avoid that problem. But I think HOTP doesn't really support rewinding very much.
But this is beside the point I was making. My point was that even if the the database was encrypted with 2FA, right after you enter your 2FA malware can steal the decrypted database out of memory.
Indeed. That's a neat plugin, each time you lock the database, it rolls forward your HOTP key some number of rounds, then uses the results of those rounds to encrypt a piece of key material for the vault. Then, when you go to decrypt, as long as your HOTP app hasn't generated more than the number of rounds it rolled forward, it can generate the decryption key from the HOTP stream and decrypt the vault. A little fragile, but a neat implementation.
> right after you enter your 2FA malware can steal the decrypted database out of memory.
There's probably a creative protection here where each key is encrypted individually, but you'd still need some solution like the above HOTP trick or the attacker could scrape the key information out of memory, then decrypt each entry individually.
>There's probably a creative protection here where each key is encrypted individually, but you'd still need some solution like the above HOTP trick or the attacker could scrape the key information out of memory, then decrypt each entry individually.
It seems to me like that would require a separate HOTP device for each password database entry, otherwise the malware can steal one HOTP token and use it against a different entry.
> It seems to me like that would require a separate HOTP device for each password database entry
That would be a paranoid level of implementation. As it sits, the HOTP device is only _sometimes_ needed depending on the caching policy. Fix that broken implementation first, then we can figure out how to update the threat model to account for an adversary that has already infected your computer.
>As it sits, the HOTP device is only _sometimes_ needed depending on the caching policy.
I don't understand what you mean. Are you talking about https://keepass.info/plugins.html#otpkeyprov or are you talking about LastPass? LastPass doesn't support HOTP AFAIK. HOTP isn't a very good form of 2FA (it's phishable, sometimes inconvenient, and it can become desynced), U2F is much better, but you can't encrypt a database with U2F.
KeepPass has a very customizable policy of when to lock the database. I have KeePass on my desktop set to lock if KeePass is inactive for 1 hour, or if my computer is inactive for 10 minutes, or if I lock my screen. Are you saying there should be a semi-locked state that requires a password but not a 2FA? Sure that's possible.
None of this protects you from malware on your computer though, so I don't know why we're talking about it.
You could ask user to present second factor (secure one, Webauthn) for every password they access. That would be a notable obstacle for me as an attacker, but I can't imagine any organization implementing this for real (maybe apart from military/spooks and their contractors). All of the IAM solutions I know of cache their creds and password manager usually is expected to work offline as well, so I don't think you can avoid having recoverable (in the CS meaning of the word) database locally.
It doesn't need to be every password, just require 2FA to unlock the vault in the first place. Downloading the vault shouldn't strip one factor, but it seems like that is the implementation.
I'm not aware of any encryption algos that can encrypt data using a rotating key such as a TOTP code. The vault file is encrypted using the master password, if you encrypted it with the TOTP code you wouldn't be able to decrypt it 30s later, and if you have logic to parse the 2FA I can just replace your logic with return true;
Wouldn't this be an implementation detail of the password manager? Either way, I hear you that this is asking for new functionality. Still, I don't think most people think that a factor disappears depending on the caching policy of the vault on your machine. It's quite a footgun.
No, since the cached data has nothing todo with the password manager. The cached data is just an encrypted file. Sure the password manager could ask for the otp but the cache file was attacked directly. That is why I was wondering if I was missing something. To my knowledge it isn't possible to protect a file with a rotating key.
> To my knowledge it isn't possible to protect a file with a rotating key.
This is my point, it is an implementation detail of the password manager to integrate OTP or another second with decryption of the vault. Any password manager can implement this.
From the perspective of the user, you are stripping a factor for some arbitrary period of time. It's a broken implementation.
That is not correct. You can not have offline caching and otp enabled at the same time. That is why things like yubikey exist. If your are not using another 2fa method besides otp it's either the security risk or entering otp each time you access the vault.
Obviously the later is not feasible.
> You can not have offline caching and otp enabled at the same time.
I'm not sure why you are having such a hard time understanding this is an implementation detail of the password manager that can change at any time. You are treating this like it cannot be implemented differently. It absolutely can.
Okay, but the attacker has RCE on the system doing the decryption, so they can scrape the encryption keys or the vault data out of memory. This appears to be a APT, probably a State-level actor. Once the production work machine was compromised, it's all over.
I'm not aware of any 2FA that could be successfully integrated into a symmetric-key encryption algorithm. How do we fix 2FA without making the entire password vault system dependent on network access to a central LP server that is not compromised?
As far as I know, no popular password manager seriously includes "fully compromised local device" in their threat model. I don't think it can be done without hurting seriously usability (like having one 2fa verification each time you use a credential would work) and the predictable outcome of hurting usability too much is that people will find more handy insecure ways to store their passwords.
> I don't think it can be done without hurting seriously usability (like having one 2fa verification each time you use a credential would work)
I wouldn’t mind tapping a YubiKey or my MacBook‘s Touch ID every time a password is accessed from the vault.
That’s essentially how ssh keys work with smartcards or security keys as a second factor.
Usually non-technical management are the ones that are against this kind of measures. This recent Passkeys initiative (that's what allows using secure enclave as a Webauthn key) is amazing though, I really hope it changes the game and maybe finally obsoletes passwords as a whole.
Also, as an aside. While correctly implemented Passkeys (without fallback auth methods) would make my life as a red teamer much harder, that would have only prevented this attack if the infected machine was engineer's private PC where they used corporate LastPass account and nothing else from their work. If the machine that's used for DevOps work gets infected, that's still and endgame because you're generating all sessions I need during your regular workday, so I don't really need the passwords / decrypted vault.
> like having one 2fa verification each time you use a credential would work
I'm interested in the technical idea here. You have a set of credentials encrypted with AES. So each vault item is encrypted with a symmetric key. How would you build a system to generate those keys using a rotating 2FA that isn't reversible by an attacker that can watch the entire process and can fake the timestamp or other elements on the computing device as needed?
I can see that you have code that enforces 2FA on each vault access, but that code is run on the local system, so it can be trivially bypassed by an attacker with root.
Don't store the encrypted passwords locally. Have them on a server that deliver them only against a valid otp/push notification confirmation on your phone/yubikey tap etc.
That's a valid solution, but I would not select a password vault that was dependent on network access. Offline access to secrets is important to me. Other people might feel differently, of course.
Absolutely agree with you. No offline access was one of the usability trade off I was referring to, that no one seems ready to make in practice.
The product I'm working on have had for a long time an option to require a second factor for each login which works a bit as at described (encrypted data are stored locally but also encrypted with a key that's stored on our servers and protected by 2fa), but at the vault level, rather than at the credential level (it doesn't protect against device compromise, but prevents brute forcing of local data for exemple. You do lose offline access) and the UX is already annoying enough that in practice this feature is very rarely used and we are regularly considering dropping it.
1Password has become really onerous to use in these days of Javascript front ends and PWA's that do norm-breaking things to the UI in a browser. I often get stuck in some sort of crazy loop trying to authenticate the browser plugin versus the app, and then have more frustrations with taps in the apps being re-captured back from the plugin. If any more frustration gets added to the workflow than I'm already experiencing, I'm going to abandon it for Apple's keychain, though I loathe the idea of letting Apple have this last piece of my personal data footprint.
Unfortunately I'm not sure I'm going to manage to sell you our product (and won't even make you the offense to try): we decided to drop our desktop apps alltogether a few years ago and we only have a browser plugin now. Also I don't think we support yubikey login anymore as a result :/ (which I think is what you are referring to by "tap").
Basically yes, but the difference in threat potential between “random person” and “person who controls access to the secure passwords of many thousands of people, most of them more tech savvy than the average user” is exponential.
No? You'd have to carry out the third-party software RCE on each individual user to install a keylogger. This attack installed a keylogger on a single computer, then exfiltrated millions of passwords. Centralization is a bad thing. Same modus operandi maybe, but nowhere near the same impact.
Yes, but the article made it seem like they had RCE to his home PC. With that they installed the keylogger to retrieve the master key which they then used to decrypt the offline vault.
I think the point is that all of the users of Lastpass whose passwords were put at risk through this one breach. Using Lastpass means that a single, high-value target is now an attack vector that can affect you. If you keep it offline yourself, you're not likely to be a high value target, and you won't have to worry about the 3rd party with your passwords being compromised.
This cannot be overstated. The online managers have an absurd amount of complexity. Just think of all the millions already spent tracing back the attack, writing these statements, all the turmoil inside the company... just for the convenience of synchronizing passwords seamlessly.
From what I can tell, all of lastpass mfa options are based around some form of otp not webauthn.
We tested the above in our own environment, since we had control of the devices we did not need urls to do it. We just grabbed the data locally to confirm if it was true. At the time lastpass told us webauthn was in the pipeline so we stayed.
The user had a keylogger installed on their machine, so the attacker could collect the master password, but how did they login to the vault on a new machine without MFA?
Did they get the MFA seed and login on a different machine, and nobody received a "You're using LastPass on a new machine, if this wasn't you..." message?
Did they exfil all that data to the compromised machine first, then out?
Unless I'm missing something, this doesn't seem right.