4 ms·

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 deriv

by 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.
  - j1elo 4y ago
    After reading you and checking the links, I am now sure the unlocking latency is not due to the number of iterations. First and foremost, because I'm using the PIN entry. And it already takes some very noticeable time to open. I do not, however, notice too much difference between using PIN or the passphrase. So the delay must come from other unrelated limitations. Thanks for all the useful info!

by jchw 4y ago

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.
- j1elo 4y ago
  After reading you and checking the links, I am now sure the unlocking latency is not due to the number of iterations. First and foremost, because I'm using the PIN entry. And it already takes some very noticeable time to open. I do not, however, notice too much difference between using PIN or the passphrase. So the delay must come from other unrelated limitations. Thanks for all the useful info!