4 ms·

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 s

by 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 j1elo 4y ago

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!