# Many consecutive hashes to slow down brute force attack?

I've heard that hash algorithms like bcrypt are more secure because they take longer to complete, and therefore take much longer to prute force, without a noticable delay for legitimate users. Would using a faster alghtithm, 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 longet than a single SHA-256 hash, wouldn't his accomplish the same thing?

-
PBKDF2 should do what you're looking for. –  Steel City Hacker May 8 '13 at 13:13

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.

-
The entropy loss due to collisions is negligible. Nobody has ever found even a single SHA-256 collision. There is no practical security difference between hashing a salted password multiple times and PBKDF2. –  CodesInChaos May 8 '13 at 8:08