3 ms·

Interesting read. While not addressed in the paper, what's a safe iteration count for password derivation algorithm like PBKDF2? Last I read it was 100,000 fo

by ww520 7y ago

Interesting read. While not addressed in the paper, what's a safe iteration count for password derivation algorithm like PBKDF2? Last I read it was 100,000 for modern machines.

tptacek 7y ago
The number of rounds in an iterated cipher is wildly different --- in fact, close to the opposite --- of the number of iterations in a password KDF. But: don't use PBKDF2 at all, if this is something you're trying to optimize; scrypt and Argon2 are memory-hard in addition to time-hard.
- ww520 7y ago
  Good to know. Yes, PBKDF2 is kind of outdated. It's just that ripping it out and replacing with new key derivation algorithms takes time, especially needing inter-operated with other tools, while the iteration count is a simple configuration to bump up on existing implementation.
ilammy 7y ago
There is no such thing. The standard recommendation is to measure how much time you spend with your hardware and adjust the iteration count to the maximum tolerable amount. The whole point of password derivation functions is to be slow, not fast. It’s just a matter of how slow is too slow. For a reference, Django currently uses 260k iterations or something like that.
- saurik 7y ago
  The hardware isn't fixed, though: I am both simultaneously writing software and deploying servers. I have an incentive to choose cheap servers, and in fact tend to run as much stuff as I can on tiny little instances that are just barely little slivers of CPU in the cloud somewhere. Locally, for app-based designs, I do a lot of work on phones, which are extremely variable. I have no clue if I am selecting numbers here large enough, and "choose what you can maximally tolerate" when you can also spend more money on faster hardware or require fancier phones from your users is nonsensical as it doesn't provide me any way to prioritize this expenditure versus other costs. I really wish someone would just tell me what I should be doing every year--including expirations on passwords or whatever else is required to deal with how the requirements change or alternatively telling me how to upgrade existing hashes to better ones (which I can never tell if the off-the-shelf algorithms even support, which is really annoying; like I would expect with something that has iterative rounds I could just iterate all my passwords a bit more every year to account for faster machines, but I think the final round is always different?)--and I can do that and feel good and point at it and say I did that.
- ww520 7y ago
  Good to know the ballpark figure for the current generation of hardware.

by ww520 7y ago

Interesting read. While not addressed in the paper, what's a safe iteration count for password derivation algorithm like PBKDF2? Last I read it was 100,000 for modern machines.

tptacek 7y ago

The number of rounds in an iterated cipher is wildly different --- in fact, close to the opposite --- of the number of iterations in a password KDF. But: don't use PBKDF2 at all, if this is something you're trying to optimize; scrypt and Argon2 are memory-hard in addition to time-hard.

ww520 7y ago
Good to know. Yes, PBKDF2 is kind of outdated. It's just that ripping it out and replacing with new key derivation algorithms takes time, especially needing inter-operated with other tools, while the iteration count is a simple configuration to bump up on existing implementation.

ilammy 7y ago

There is no such thing. The standard recommendation is to measure how much time you spend with your hardware and adjust the iteration count to the maximum tolerable amount. The whole point of password derivation functions is to be slow, not fast. It’s just a matter of how slow is too slow. For a reference, Django currently uses 260k iterations or something like that.

saurik 7y ago
The hardware isn't fixed, though: I am both simultaneously writing software and deploying servers. I have an incentive to choose cheap servers, and in fact tend to run as much stuff as I can on tiny little instances that are just barely little slivers of CPU in the cloud somewhere. Locally, for app-based designs, I do a lot of work on phones, which are extremely variable. I have no clue if I am selecting numbers here large enough, and "choose what you can maximally tolerate" when you can also spend more money on faster hardware or require fancier phones from your users is nonsensical as it doesn't provide me any way to prioritize this expenditure versus other costs. I really wish someone would just tell me what I should be doing every year--including expirations on passwords or whatever else is required to deal with how the requirements change or alternatively telling me how to upgrade existing hashes to better ones (which I can never tell if the off-the-shelf algorithms even support, which is really annoying; like I would expect with something that has iterative rounds I could just iterate all my passwords a bit more every year to account for faster machines, but I think the final round is always different?)--and I can do that and feel good and point at it and say I did that.
ww520 7y ago
Good to know the ballpark figure for the current generation of hardware.