Sebastiaan van Erk wrote:
Next he goes on to state:"Speed is exactly what you don’t want in a password hash function.""You don’t care if password tests take twice as long, or even ten times as long, because password hashes aren’t in the 80/20 hot spot.""Now the attacker. This is easy. The attacker cares a lot if password tests take twice as long. If one password test takes twice as long, the total password cracking time takes twice as long."But if you add 2 characters to your salt you increase your search space by a factor 3844. And that's just 2 characters; this technique is scalable. Add 10 characters to your salt and you increase the time it takes to crack (brute force) by a factor of 839299365868340224. Obviously you can't make a hash function 839299365868340224 times slower because it won't be able to check your password when you log in.
Oops, bit trigger happy on that one. ;-) Of course slowing down your hash function DOES help against dictionary attacks and brute force on the password itself (instead of on the hash). However, even if you slow it down to 1 second per hash a cracker will easily be able to do dictionary attacks with his botnet, so it does not adequately protect weak passwords anyway. And 1 second per hash is quite expensive for a high volume site. So I still think you're better of make sure you don't lose your password database instead of making the login slow.
Regards, Sebastiaan
smime.p7s
Description: S/MIME Cryptographic Signature
