Many consecutive hashes to slow down brute force attack?

Question

I've heard that hash algorithms like bcrypt are more secure because they take longer to complete, and therefore take much longer to brute force, without a noticeable delay for legitimate users. Would using a faster algorithm, such as SHA-256, multiple times, be secure? For example:

hash = "password"
for x in range(5000):
    hash = hashlib.sha256(hash).hexdigest

As it has to hash the data, then hash the hash, and so on, taking much longer than a single SHA-256 hash, wouldn't this accomplish the same thing?

Answer 1

Instead of that home-grown scheme, I would use PBKDF2 instead if you simply are sold on the idea of iterated hash schemes. It uses an such a scheme, although not exactly the one you have described, and is well-studied and considered secure.

However, PBKDF2 doesn't offer many advantages over bcrypt, as PBKDF2 is still vulnerable to GPU and FPGA/ASIC brute-force attacks. bcrypt resists GPU brute-forcing because of the 4K table used in the algorithm, which forces contention for the global memory bus in GPUs. But bcrypt is still potentially vulnerable to FPGA/ASIC attacks, although most people don't have to worry about that.

A newer KDF, scrypt, is also tunable for the amount of memory it uses, so it is more resistant (when properly tuned) to FPGA/ASIC attacks than bcrypt. However, scrypt is relatively new (2009) when compared to bcrypt (1999), so that may make you somewhat nervous.

Essentially, to store passwords, you should be probably using bcrypt, since it seems to hit a sweet spot of being GPU resistant as well as being sufficiently mature. But PBKDF2 and scrypt are still good; using any one of the three is really fine.

For more information, I would recommend looking at the following question which has an (excellent) top answer by Thomas Pornin: Do any security experts recommend bcrypt for password storage? He is infinitely more credentialed than I am, so if you don't believe me, hopefully his testimony will be compelling.

Answer 2

The scheme you described above has some flaws. Because you aren't seeding the hash input each iteration, you are really increasing your chance of getting collisions. This is a great example of why you should try to avoid implementing these things yourself. It's really easy to overlook something subtle that undermines your system's security.

As previously mentioned, it's much safer (and easier!) to use a well tested solution that does this for you (bcrypt, PBKDF2, etc), rather than to try to build it yourself.