3 ms·

Wait, 10,000 iterations of the has function? That's surprising, and of questionable value.

alltakendamned 10y ago
Yes, at least. _and_ in combination with a slow hashing function such as PBKDF-2, where the current recommendation for server side hashing is 100K+ iterations. The workload is ideally set to something that is acceptable to users, but considerably slows down brute-force attempts by attackers. Please educate yourself some more before making statements on the value of things that surprise you, they might be there for a good reason.
- Pxtl 10y ago
  Doesnt this leave your auth system very vulnerable to DDOS?
  - alltakendamned 10y ago
    Well, the calculation of the hash on the server side will of course also be a tiny bit slower, but this will seldom significantly increase the risk of application level DDOS, also because you can size the machines according to your needs. Also, even 10s of thousands of iterations are very fast (run `openssl speed` to get an idea). See this more as a mechanism to introduce 8-10 ms delay for every password check. This will delay the attacker, but shouldn't bring down a server. This does not have any impact on network-level DDOS scenarios. In short, in password authentication, slower is better.
  - KayEss 10y ago
    Only if you don't also implement the limiting that is also described.
- protonfish 10y ago
  The brute force would have to be on a raw database dump, and is probably in no rush to complete. Also, speed being hardware dependent, the attacker could simply get more, or wait for the advance of Moore's law so that what was "slow" last year is now fast. Deliberately slow hashing is just shouting into the wind. Your comment about "please educate yourself" was not constructive.
  - nommm-nommm 10y ago
    The parent comment of educating yourself refers to the fact that using a slow hash function and using multiple iterations has be password storing best practice for many years. Its neither surprising (rather expected) nor of questionable value.
  - taco_emoji 10y ago
    You don't seem to understand the scale here. Normal, non-secure hash functions can be calculated at a rate of hundreds of millions per second, and can easily be brute-forced within a few hours. Current rule of thumb for PBKDF2 (for example) is to choose an iteration count corresponding to around two hashes per second, and the work is not parallelizable. That turns those hours of work into millenia. If it really concerns you, proper practice is to store the iteration count alongside the hash and salt, so you can easily go through and add more iterations if you want as computers get faster.
- user5994461 10y ago
  100k iterations = 400 ms of computation. The NIST recommendation for "highly sensitive access" is 10M iterations :D

Yes, at least. _and_ in combination with a slow hashing function such as PBKDF-2, where the current recommendation for server side hashing is 100K+ iterations. The workload is ideally set to something that is acceptable to users, but considerably slows down brute-force attempts by attackers. Please educate yourself some more before making statements on the value of things that surprise you, they might be there for a good reason.

Pxtl 10y ago
Doesnt this leave your auth system very vulnerable to DDOS?
- alltakendamned 10y ago
  Well, the calculation of the hash on the server side will of course also be a tiny bit slower, but this will seldom significantly increase the risk of application level DDOS, also because you can size the machines according to your needs. Also, even 10s of thousands of iterations are very fast (run `openssl speed` to get an idea). See this more as a mechanism to introduce 8-10 ms delay for every password check. This will delay the attacker, but shouldn't bring down a server. This does not have any impact on network-level DDOS scenarios. In short, in password authentication, slower is better.
- KayEss 10y ago
  Only if you don't also implement the limiting that is also described.
protonfish 10y ago
The brute force would have to be on a raw database dump, and is probably in no rush to complete. Also, speed being hardware dependent, the attacker could simply get more, or wait for the advance of Moore's law so that what was "slow" last year is now fast. Deliberately slow hashing is just shouting into the wind. Your comment about "please educate yourself" was not constructive.
- nommm-nommm 10y ago
  The parent comment of educating yourself refers to the fact that using a slow hash function and using multiple iterations has be password storing best practice for many years. Its neither surprising (rather expected) nor of questionable value.
- taco_emoji 10y ago
  You don't seem to understand the scale here. Normal, non-secure hash functions can be calculated at a rate of hundreds of millions per second, and can easily be brute-forced within a few hours. Current rule of thumb for PBKDF2 (for example) is to choose an iteration count corresponding to around two hashes per second, and the work is not parallelizable. That turns those hours of work into millenia. If it really concerns you, proper practice is to store the iteration count alongside the hash and salt, so you can easily go through and add more iterations if you want as computers get faster.
user5994461 10y ago
100k iterations = 400 ms of computation. The NIST recommendation for "highly sensitive access" is 10M iterations :D