For awhile I have been looking for a more secure way to hash a user's password on my website, to be inserted into a database. I have looked into all of the hashing methods available. It's been said that bcrypt is the best because of its slowness. I was thinking that, if I don't need the highest security of, but still staying safe. What if I used sha512 and then md5 on that hash. Would it matter if I reversed the order of the hashing? Keep in mind I will be using a separate salt for each operation. How safe would this be? Are there an other combinations that would do the same?
2 Answers
Any custom method you invent is more likely to have subtle bugs which make your storage method vulnerable. It's not worth the effort, since you're not likely to find these subtle bugs until it's too late. It's much better to use something that has been tried and tested.
Generally, these are your choices when storing a password,
- Use bcrypt.
- Use a salted, strengthened hash.
The first method is easy, just use bcrypt. It's support in pretty much any language, and has been widely used and tested to ensure it's security.
The second method requires you to use a general purpose hash function (SHA-2 family or better, not MD5 or SHA-1 as they're broken/weak) or better yet, a HMAC, create a unique salt for the user and a unique application wide salt, and then iterate the hash function many times (100,000, etc) to slow it down (called key stretching/strengthening).
e.g. (pseudocode)
sofar = hash("sha512", user_salt + site_salt + input_password);
iterations = 100000; // Should be changed based on hardware speed
while (iterations > 0)
{
sofar = hash("sha512", user_salt + site_salt + sofar);
iterations--;
}
user.save("password", "$sha512$" + user_salt + "$" + iterations + "$" + sofar);
Each iteration should rely on the previous iteration so someone can't parallelize a brute force method to break it. Likewise, the number of iterations should be changed based on the speed of your hardware so that the process is slow enough. Slower is better when it comes to password hashing.
Summary
Use bcrypt.

- 26,096
- 4
- 39
- 62
-
Ok I will use bcrypt. Thanks for the help! – Sneitzke38 Dec 22 '11 at 00:32
I don't see the point of employing MD5 at all. It's broken. But multiple rounds is apparently stronger. However the improvement from two rounds is unlikely to make much difference. Applying SHA512 lots and lots of times would be better.
You should instead be looking at user password length and salting the passwords if you're not already doing so
Is "double hashing" a password less secure than just hashing it once? provides a detailed commentary on multiple rounds of an algorithm.
In reality I suspect that the number of SHA-512'd passwords cracked are small and there are more important things to worry about like preventing them seeing the passwords in the first place - ensuring your system is safe from SQL injection, privilege escalation, etc.

- 1
- 1

- 4,293
- 3
- 23
- 36