3 ms·
Short version (you almost got around to it, but didn't explicitly state it :)) -- Don't use straight hash functions because they are made to be fast. Even if
by seiji 16y ago
Short version (you almost got around to it, but didn't explicitly state it :)) -- Don't use straight hash functions because they are made to be fast. Even if you salt/nonce them, you can generate private rainbow tables quickly.
Use a password hiding method that's slow to compute (slow being "this operation isn't implemented in hardware or optimized assembly") which is what bcrypt or scrypt provides.
Differences in speed/effort are mentioned at http://www.tarsnap.com/scrypt.html http://www.tarsnap.com/scrypt.html -- scrypt enc is approximately 100 billion times more than the cost of cracking the same password on a file encrypted by openssl enc
- lonestar 16y agoActually, slow in this case does not at all mean "this operation isn't implemented in hardware or optimized assembly". The slowness of an algorithm like bcrypt is a tunable property of the key expansion algorithm. A step in this process will be repeated 2^n times, where n can be configured by the user. If a password function was only slow because it wasn't implemented in assembly on your server, an attacker would obviously just go implement it in assembly for his brute-force crack.
- tptacek 16y agoActually, the major contribution in Colin's scrypt work is to find primitives that don't admit as well to hardware acceleration; his hypothesis is that one of bcrypt's weaknesses is that even though it's very slow in software, it might be possible to massively accelerate it with FPGAs.