3 ms·
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
by 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 agoThe 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 agoYou 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.