4 ms·

> Both Bitwarden and LastPass should improve this situation by making the iteration count automatically increase over time. Bitwarden does let you increase the

> 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/
- j1elo 4y ago
  Bitwarden already takes a couple of instants more than I'd like, each time the vault is unlocked in my phone. It's always one of those moments where I'm doing something that requires a new login, and usually the step of having to derive attention to the password manager is an undesired distraction, agravated by watching an idle screen for at least a couple of seconds while the vault decides to open, and at last I can search for my secret and continue what I was doing... I do not use biometric because they fail a lot on me (fuzzy fingerprints due to stuff) It's not even a nitpicky complaint I'm dropping in the internet, it does really bother me absolutely every time. Making it even slower, please no.
  - dataspun 4y ago
    > fuzzy fingerprints due to stuff lol
  - jchw 4y ago
    If you are using PIN entry: It's the same story. Key derivation is only occurring when you actually unlock the vault, in other cases the passphrase is not used and therefore key derivation is not needed. If PIN unlocks are taking too long, it has nothing to do with PBKDF2. If you're entering the master passphrase every time: Obviously this has the benefit of not keeping the derived key cached anywhere, even if where it's cached is 'secure'. However, if you choose a slightly less secure key, even just a couple of characters shorter, you have to keep in mind that this dramatically lowers your security. You are better off avoiding this and using features that cache the derived key on mobile devices where it's feasible to do this. Nobody is suggesting you can't use less secure settings to make up for having slow devices. You totally can. The defaults, however, should not be designed around your needs. They should be designed around security tradeoffs that give the best outcome to the broader public. People with special requirements should be the ones touching settings like this. I'm not sure you're actually dealing with a problem where PBKDF2 iterations are eating up a significant amount of time, though. You may just be underestimating how many iterations of PBKDF2 can fit in a second on a modern mobile SoC. I would actually guess that the reason why opening the vault takes long is unrelated to the actual unlocking process. edit: To make it more explicit, check out this benchmark from 2012 of a pure JavaScript PBKDF2 implementation. https://wiki.allizom.org/SJCL_PBKDF2_Benchmark https://wiki.allizom.org/SJCL_PBKDF2_Benchmark If a Google Nexus One can get 38k iterations/s on a 2010 SoC using a pure JavaScript implementation of PBKDF2 (using old browsers even!), I can assure you that the time it takes to do a couple hundred thousand rounds in native code is absolutely nothing at all on a phone from a few years later.

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/

j1elo 4y ago
Bitwarden already takes a couple of instants more than I'd like, each time the vault is unlocked in my phone. It's always one of those moments where I'm doing something that requires a new login, and usually the step of having to derive attention to the password manager is an undesired distraction, agravated by watching an idle screen for at least a couple of seconds while the vault decides to open, and at last I can search for my secret and continue what I was doing... I do not use biometric because they fail a lot on me (fuzzy fingerprints due to stuff) It's not even a nitpicky complaint I'm dropping in the internet, it does really bother me absolutely every time. Making it even slower, please no.
- dataspun 4y ago
  > fuzzy fingerprints due to stuff lol
- jchw 4y ago
  If you are using PIN entry: It's the same story. Key derivation is only occurring when you actually unlock the vault, in other cases the passphrase is not used and therefore key derivation is not needed. If PIN unlocks are taking too long, it has nothing to do with PBKDF2. If you're entering the master passphrase every time: Obviously this has the benefit of not keeping the derived key cached anywhere, even if where it's cached is 'secure'. However, if you choose a slightly less secure key, even just a couple of characters shorter, you have to keep in mind that this dramatically lowers your security. You are better off avoiding this and using features that cache the derived key on mobile devices where it's feasible to do this. Nobody is suggesting you can't use less secure settings to make up for having slow devices. You totally can. The defaults, however, should not be designed around your needs. They should be designed around security tradeoffs that give the best outcome to the broader public. People with special requirements should be the ones touching settings like this. I'm not sure you're actually dealing with a problem where PBKDF2 iterations are eating up a significant amount of time, though. You may just be underestimating how many iterations of PBKDF2 can fit in a second on a modern mobile SoC. I would actually guess that the reason why opening the vault takes long is unrelated to the actual unlocking process. edit: To make it more explicit, check out this benchmark from 2012 of a pure JavaScript PBKDF2 implementation. https://wiki.allizom.org/SJCL_PBKDF2_Benchmark https://wiki.allizom.org/SJCL_PBKDF2_Benchmark If a Google Nexus One can get 38k iterations/s on a 2010 SoC using a pure JavaScript implementation of PBKDF2 (using old browsers even!), I can assure you that the time it takes to do a couple hundred thousand rounds in native code is absolutely nothing at all on a phone from a few years later.