5 ms·

While the practice of not updating PBKDF2 iterations is bad, I think with LastPass the problem was more the aggregate of many things, a sort-of death by a milli

by jchw 4y ago

While the practice of not updating PBKDF2 iterations is bad, I think with LastPass the problem was more the aggregate of many things, a sort-of death by a million cuts. Because truthfully, the PBKDF2 iterations count issue was relatively unimportant. Some good conjecture about it: https://neilmadden.blog/2023/01/09/on-pbkdf2-iterations/ https://neilmadden.blog/2023/01/09/on-pbkdf2-iterations/ Both Bitwarden and LastPass should improve this situation by making the iteration count automatically increase over time. For LastPass though, there are... A lot of concerns. The breach, how it was handled, persistent issues with the security of their browser extension (many, including an RCE at one point) and of course the fact that not everything in the vault is actually encrypted. KeePass XC or 1password may prove to be better options from a strict security practices standpoint, but from what I've seen I don't suspect Bitwarden has a pattern of bad security practices overall. It does seem like there are opportunities to make it better, though.

danenania 4y ago
We took a similar approach to passphrase stretching in EnvKey v1 [1] (EnvKey is a secrets manager, not a password manager, but uses end-to-end encryption in a similar way). We used PBKDF2 with iterations set a bit higher than the generally recommended levels, as well as Dropbox's zxcvbn [2] lib to try to identify and block weak passphrases. Ultimately, I think it's just not good enough. Even if you're updating iteration counts automatically (which is clearly not a safe assumption, and to be fair not something we did in EnvKey v1 either), and even with safeguards against weak passphrases, using human-generated passphrases as a single line of defense is just fundamentally weak. That's why in EnvKey v2, we switched to using high entropy device-based keys for our root encryption keys. It's a similar model to SSH, except that on Mac and Windows the keys get stored in the OS keychain rather than in the file system. Also like SSH, a passphrase can optionally be added on top of the device key. The downside (or upside, depending how you look at it) is that new devices must be specifically granted access. You can't just log in and decrypt on a new device with only your passphrase. But the security is much stronger, and you also avoid all this song and dance around key stretching iterations. 1 - https://github.com/envkey/envkey https://github.com/envkey/envkey 2 - https://github.com/dropbox/zxcvbn https://github.com/dropbox/zxcvbn
- nequo 4y ago
  That sounds like a good idea. Using device-specific keys sounds a lot like Keybase to my naïve ears. Are there any major differences in your design and theirs?
  - danenania 4y ago
    I'm not deeply familiar with Keybase's design, but speaking in broad strokes, our approach is similar. That said, one area that Keybase compromised on that we haven't is offering a web interface. It's well known among security and encryption people that you can't do serious end-to-end encryption in a web app--an attacker with access to the server can just modify the html/js payload, rendering the encryption pointless. Of course, web interfaces are convenient and users want them, so many products give in on this for the sake of UX even though it fully undermines the zero-trust model. EnvKey hasn't though. It has a desktop app and a CLI--there's no web interface.
    - eloeffler 4y ago
      This is especially bothersome with Bitwarden and the reason I ditched it shortly after trying it. You can use the desktop/mobile clients, but some functions require the use of the web UI and that's a dealbreaker for me... I wish there was a browser plugin that verifies the congruence of the web UI with upstream source - or even better a client that supports all functions that the web UI supports.
  - deleted 4y ago
    [deleted]
- nine_k 4y ago
  What are your expected failure modes? Consider this pretty common scenario: ahe user lost their one and only enrolled device. How can the user reinstate access? I suppose the user must have printed the real root password / secret key / whatever and put the paper somewhere in a safe. That password should allow to reinstate access when all hardware is lost. But it should not be required daily.
NoPicklez 4y ago
I still think it's maddening that LastPass's website says that the vault is encrypted, yet in reality that wasn't and may still not be the case, where aspects of the vault as we now know aren't encrypted. Unless I'm missing something, to me that is one of the biggest failures. It is even laid out in their technical and organizational measures document.
- mtlmtlmtlmtl 4y ago
  Software companies should really be held more accountable for outright lies like this. It's a very widespread practice.
  - NoPicklez 4y ago
    100% They tout on their website that they get third party assurance testing done and yet none of it matters if we can’t see the actual reports. I just can’t believe more people aren’t enraged about it. Or that people aren’t seeking to sue, purely based on that. Zero trust architecture is fine if you’re breached that’s the whole point, but saying that the information within the vault is encrypted when parts of it aren’t is downright malicious.
  - neuronic 4y ago
    Agreed, in fact LastPass should be heavily fined for this and be forced to go out of business if things don't provably change within a reasonable timeframe.
krimpenrik 4y ago
Just got word that one of my team members runner the python script to extract the seeds out of LastPass. Excited to leave LP and move to bitwarden. Like you said, a lot of small stuff at LP is the issue, unresponsive plugin sometimes, got a update and new UI last week, now the search in the chrome plugin isn't working on my end, really don't understand how you can write such shitty software for something so simpel (the UI part)
rstuart4133 4y ago
> Both Bitwarden and LastPass should improve this situation by making the iteration count automatically increase over time. Bitwarden does let you increase the number of PBKDF2 iterations through a setting, they they also provide this warning: > Warning: Setting your KDF iterations too high could result in poor performance when logging into (and unlocking) Bitwarden on devices with slower CPUs. We recommend that you increase the value in increments of 50,000 and then test all of your devices. Translation: upping this could make your old device very slow. I'm not sure I'd want to be receiving end of a whole pile of users complaining Bitwarden is becoming unusable on their current devices because they silently upped it, so I'm be leery of upping for existing users too. As for the server side key issue highlighted in the article: they have a point; it could be done better. But it's already pretty good, and if that's the only issue it's the least of my concerns. It's only a concern if a hacker got read access to the server, but read access means they've been compromised. And if they've been compromised those same people might have write access. If someone gets write access to Bitwarden's servers, then all bets are off. They can just modify the javascript to send themselves my unencrypted key. Then there is the /dev/mem thing. The bottom line is if someone has access to your machines RAM, then you can likely see the entire database unencrypted. Is your Windows desktop "corporate managed"? If so, I'm looking at you, sir. While Linux / Android / iOS are more protective of their users than Microsoft (who seems hell bent on selling their soul to their corporate customers), they aren't whole pile better. They may not sell their soul to high paying corporate customers, but they will still do whatever their governments ask and you will be none the wiser. The bottom line is all these proprietary solutions suffer from this "we won't let you see but we promise you can trust us" flaw. I refused to use LastPass because it was hopeless in that respect, and later their promises turned out to be hollow. With Bitwarden there is a lot less trust involved because we can inspect the code they promise we are running.
- jchw 4y ago
  Nit: yes, it's true that making the iteration count high could actually make some devices unlock very slowly. BUT: - This only occurs when performing key derivation, i.e. when you're unlocking. It does not matter once the key is in memory. Therefore, it's actually OK if it takes a few seconds. When unlocking with biometrics, the key derivation function is not used, so on mobile devices, this occurs even less often. - PBKDF2 is very fast. A few hundred thousand iterations is not going to be a noticeable hitch on old SoCs anymore. I actually suspect the real problem was JavaScript/webextensions/the web vault. However, it's probably a non-issue now that all browsers have decent WebCrypto implementations with PBKDF2 support. The difference between JS and native code is very noticeable with cryptographic code. Even then, it might be less of a problem now with improvements to JavaScript engines and WASM. I generally pick open source solutions over closed source ones, and Bitwarden does check that box, but to be fair, so does KeePass XC and compatible mobile companions. I like Bitwarden as an easy tool to recommend to friends, but for power users KeePass XC is certainly worth a look. They came out looking pretty good when security researchers began approaching ways to attack the clients themselves: https://keepassxc.org/blog/2019-02-21-memory-security/ https://keepassxc.org/blog/2019-02-21-memory-security/
hiimkeks 4y ago
They shouldn't be using PBKDF2 for new installations at all. It's been nearly a decade since the Password Hashing Competition, and you should just use the memory-hard Argon2. Also, W3C should finally get it into the WebCrypto API, but it seems like whoever is responsible for it just let's that API rot. There are fast wasm implementations, though.
- jchw 4y ago
  Memory-hard is not a panacea. I think the point, which is pretty well made by the blog post I linked to, is that the security of the vault is extremely sensitive to the passphrase anyways. Adding more PBKDF2 rounds is a nearly free way to make bruteforcing harder, whereas switching to Argon2 or scrypt or bcrypt or any other KDF requires more effort, not to mention yes, lacking Webcrypto support is a significant performance problem (WASM Argon2 implementations are at least multiple times slower than native IIRC.)
  - hiimkeks 4y ago
    > Adding more PBKDF2 rounds is a nearly free way to make bruteforcing harder, whereas switching to Argon2 or scrypt or bcrypt or any other KDF requires more effort The way I see it it's the other way around. The only complexity cost that lives here is that you need to distinguish between different derivation configurations. Whether that configuration tells you to use PBKDF2-200000 or Argon2-64M-4-1 doesn't matter, and you'll have to add a clause to the code either way. On the flipside, the memory-hardness allows you to increase the cost for the attacker a lot more than for the user. > WASM Argon2 implementations are at least multiple times slower than native IIRC I haven't looked this up, but my suspicion is that it's still better than a WebCrypto PBKDF2 configuration taking the same time for the user, measured in Wh for the attacker.
    - jchw 4y ago
      Just to be clear, the cost of changing the iterations is almost zero. Bitwarden already supports variable PBKDF2 rounds on all platforms, as well as changing the number of rounds. I'm sorry, but the cost of deploying Argon2 in production to a lot of platforms across a lot of devices is non-trivial by comparison. If you have enough different combinations of devices and environments deploying an if statement can become a challenge. In this case, it's especially a problem considering the lack of Webcrypto support. By all means, use Argon2 in new code, or any other more modern KDF. But PBKDF2 isn't broken, and replacing it warrants actually doing the ground work to see if it makes sense: is it fast enough on most devices? is the security improvement meaningful enough? etc. The truth is, 1password has the right idea here with their Master Key system. Even very unwieldy long passwords are pretty low entropy compared to a proper cryptographic key, and KDFs cannot significantly improve this situation. If you want to do more than re-inforce the speed bump, you're going to need to work outside the password. It has a usability trade-off of course, so maybe it's good that not everyone does it that way.
tablespoon 4y ago
> I think with LastPass the problem was more the aggregate of many things, a sort-of death by a million cuts. That's true. > Because truthfully, the PBKDF2 iterations count issue was relatively unimportant. IIRC, some people's LastPass vaults were set to use a very old default of a single PBKDF2 iteration, which I understand is basically nothing, nowadays.
- jerf 4y ago
  As of three weeks ago, mine was set to 500, so I can confirm that low, at least. Plenty of master password changes in the past several years, so plenty of opportunities for it to have been automatically set higher. The only reason I hadn't set it higher myself is I didn't know it was a setting at all.

by jchw 4y ago

danenania 4y ago

We took a similar approach to passphrase stretching in EnvKey v1 [1] (EnvKey is a secrets manager, not a password manager, but uses end-to-end encryption in a similar way). We used PBKDF2 with iterations set a bit higher than the generally recommended levels, as well as Dropbox's zxcvbn [2] lib to try to identify and block weak passphrases. Ultimately, I think it's just not good enough. Even if you're updating iteration counts automatically (which is clearly not a safe assumption, and to be fair not something we did in EnvKey v1 either), and even with safeguards against weak passphrases, using human-generated passphrases as a single line of defense is just fundamentally weak. That's why in EnvKey v2, we switched to using high entropy device-based keys for our root encryption keys. It's a similar model to SSH, except that on Mac and Windows the keys get stored in the OS keychain rather than in the file system. Also like SSH, a passphrase can optionally be added on top of the device key. The downside (or upside, depending how you look at it) is that new devices must be specifically granted access. You can't just log in and decrypt on a new device with only your passphrase. But the security is much stronger, and you also avoid all this song and dance around key stretching iterations. 1 - https://github.com/envkey/envkey https://github.com/envkey/envkey 2 - https://github.com/dropbox/zxcvbn https://github.com/dropbox/zxcvbn

nequo 4y ago
That sounds like a good idea. Using device-specific keys sounds a lot like Keybase to my naïve ears. Are there any major differences in your design and theirs?
- danenania 4y ago
  I'm not deeply familiar with Keybase's design, but speaking in broad strokes, our approach is similar. That said, one area that Keybase compromised on that we haven't is offering a web interface. It's well known among security and encryption people that you can't do serious end-to-end encryption in a web app--an attacker with access to the server can just modify the html/js payload, rendering the encryption pointless. Of course, web interfaces are convenient and users want them, so many products give in on this for the sake of UX even though it fully undermines the zero-trust model. EnvKey hasn't though. It has a desktop app and a CLI--there's no web interface.
  - eloeffler 4y ago
    This is especially bothersome with Bitwarden and the reason I ditched it shortly after trying it. You can use the desktop/mobile clients, but some functions require the use of the web UI and that's a dealbreaker for me... I wish there was a browser plugin that verifies the congruence of the web UI with upstream source - or even better a client that supports all functions that the web UI supports.
- deleted 4y ago
  [deleted]
nine_k 4y ago
What are your expected failure modes? Consider this pretty common scenario: ahe user lost their one and only enrolled device. How can the user reinstate access? I suppose the user must have printed the real root password / secret key / whatever and put the paper somewhere in a safe. That password should allow to reinstate access when all hardware is lost. But it should not be required daily.

NoPicklez 4y ago

I still think it's maddening that LastPass's website says that the vault is encrypted, yet in reality that wasn't and may still not be the case, where aspects of the vault as we now know aren't encrypted. Unless I'm missing something, to me that is one of the biggest failures. It is even laid out in their technical and organizational measures document.

mtlmtlmtlmtl 4y ago
Software companies should really be held more accountable for outright lies like this. It's a very widespread practice.
- NoPicklez 4y ago
  100% They tout on their website that they get third party assurance testing done and yet none of it matters if we can’t see the actual reports. I just can’t believe more people aren’t enraged about it. Or that people aren’t seeking to sue, purely based on that. Zero trust architecture is fine if you’re breached that’s the whole point, but saying that the information within the vault is encrypted when parts of it aren’t is downright malicious.
- neuronic 4y ago
  Agreed, in fact LastPass should be heavily fined for this and be forced to go out of business if things don't provably change within a reasonable timeframe.

krimpenrik 4y ago

Just got word that one of my team members runner the python script to extract the seeds out of LastPass. Excited to leave LP and move to bitwarden. Like you said, a lot of small stuff at LP is the issue, unresponsive plugin sometimes, got a update and new UI last week, now the search in the chrome plugin isn't working on my end, really don't understand how you can write such shitty software for something so simpel (the UI part)

rstuart4133 4y ago

> Both Bitwarden and LastPass should improve this situation by making the iteration count automatically increase over time. Bitwarden does let you increase the number of PBKDF2 iterations through a setting, they they also provide this warning: > Warning: Setting your KDF iterations too high could result in poor performance when logging into (and unlocking) Bitwarden on devices with slower CPUs. We recommend that you increase the value in increments of 50,000 and then test all of your devices. Translation: upping this could make your old device very slow. I'm not sure I'd want to be receiving end of a whole pile of users complaining Bitwarden is becoming unusable on their current devices because they silently upped it, so I'm be leery of upping for existing users too. As for the server side key issue highlighted in the article: they have a point; it could be done better. But it's already pretty good, and if that's the only issue it's the least of my concerns. It's only a concern if a hacker got read access to the server, but read access means they've been compromised. And if they've been compromised those same people might have write access. If someone gets write access to Bitwarden's servers, then all bets are off. They can just modify the javascript to send themselves my unencrypted key. Then there is the /dev/mem thing. The bottom line is if someone has access to your machines RAM, then you can likely see the entire database unencrypted. Is your Windows desktop "corporate managed"? If so, I'm looking at you, sir. While Linux / Android / iOS are more protective of their users than Microsoft (who seems hell bent on selling their soul to their corporate customers), they aren't whole pile better. They may not sell their soul to high paying corporate customers, but they will still do whatever their governments ask and you will be none the wiser. The bottom line is all these proprietary solutions suffer from this "we won't let you see but we promise you can trust us" flaw. I refused to use LastPass because it was hopeless in that respect, and later their promises turned out to be hollow. With Bitwarden there is a lot less trust involved because we can inspect the code they promise we are running.

jchw 4y ago
Nit: yes, it's true that making the iteration count high could actually make some devices unlock very slowly. BUT: - This only occurs when performing key derivation, i.e. when you're unlocking. It does not matter once the key is in memory. Therefore, it's actually OK if it takes a few seconds. When unlocking with biometrics, the key derivation function is not used, so on mobile devices, this occurs even less often. - PBKDF2 is very fast. A few hundred thousand iterations is not going to be a noticeable hitch on old SoCs anymore. I actually suspect the real problem was JavaScript/webextensions/the web vault. However, it's probably a non-issue now that all browsers have decent WebCrypto implementations with PBKDF2 support. The difference between JS and native code is very noticeable with cryptographic code. Even then, it might be less of a problem now with improvements to JavaScript engines and WASM. I generally pick open source solutions over closed source ones, and Bitwarden does check that box, but to be fair, so does KeePass XC and compatible mobile companions. I like Bitwarden as an easy tool to recommend to friends, but for power users KeePass XC is certainly worth a look. They came out looking pretty good when security researchers began approaching ways to attack the clients themselves: https://keepassxc.org/blog/2019-02-21-memory-security/ https://keepassxc.org/blog/2019-02-21-memory-security/

hiimkeks 4y ago

They shouldn't be using PBKDF2 for new installations at all. It's been nearly a decade since the Password Hashing Competition, and you should just use the memory-hard Argon2. Also, W3C should finally get it into the WebCrypto API, but it seems like whoever is responsible for it just let's that API rot. There are fast wasm implementations, though.

jchw 4y ago
Memory-hard is not a panacea. I think the point, which is pretty well made by the blog post I linked to, is that the security of the vault is extremely sensitive to the passphrase anyways. Adding more PBKDF2 rounds is a nearly free way to make bruteforcing harder, whereas switching to Argon2 or scrypt or bcrypt or any other KDF requires more effort, not to mention yes, lacking Webcrypto support is a significant performance problem (WASM Argon2 implementations are at least multiple times slower than native IIRC.)
- hiimkeks 4y ago
  > Adding more PBKDF2 rounds is a nearly free way to make bruteforcing harder, whereas switching to Argon2 or scrypt or bcrypt or any other KDF requires more effort The way I see it it's the other way around. The only complexity cost that lives here is that you need to distinguish between different derivation configurations. Whether that configuration tells you to use PBKDF2-200000 or Argon2-64M-4-1 doesn't matter, and you'll have to add a clause to the code either way. On the flipside, the memory-hardness allows you to increase the cost for the attacker a lot more than for the user. > WASM Argon2 implementations are at least multiple times slower than native IIRC I haven't looked this up, but my suspicion is that it's still better than a WebCrypto PBKDF2 configuration taking the same time for the user, measured in Wh for the attacker.
  - jchw 4y ago
    Just to be clear, the cost of changing the iterations is almost zero. Bitwarden already supports variable PBKDF2 rounds on all platforms, as well as changing the number of rounds. I'm sorry, but the cost of deploying Argon2 in production to a lot of platforms across a lot of devices is non-trivial by comparison. If you have enough different combinations of devices and environments deploying an if statement can become a challenge. In this case, it's especially a problem considering the lack of Webcrypto support. By all means, use Argon2 in new code, or any other more modern KDF. But PBKDF2 isn't broken, and replacing it warrants actually doing the ground work to see if it makes sense: is it fast enough on most devices? is the security improvement meaningful enough? etc. The truth is, 1password has the right idea here with their Master Key system. Even very unwieldy long passwords are pretty low entropy compared to a proper cryptographic key, and KDFs cannot significantly improve this situation. If you want to do more than re-inforce the speed bump, you're going to need to work outside the password. It has a usability trade-off of course, so maybe it's good that not everyone does it that way.

tablespoon 4y ago

> I think with LastPass the problem was more the aggregate of many things, a sort-of death by a million cuts. That's true. > Because truthfully, the PBKDF2 iterations count issue was relatively unimportant. IIRC, some people's LastPass vaults were set to use a very old default of a single PBKDF2 iteration, which I understand is basically nothing, nowadays.

jerf 4y ago
As of three weeks ago, mine was set to 500, so I can confirm that low, at least. Plenty of master password changes in the past several years, so plenty of opportunities for it to have been automatically set higher. The only reason I hadn't set it higher myself is I didn't know it was a setting at all.