I read online that it's useless and basically impractical to hash a password with multiple hashing algorithms (and not just one) before storing them in a database. I don't really understand why that is. If someone gets their hands on a list of hashes and he doesn't know which hash functions were used, how can the passwords be cracked? It would seem that using a combination of multiple hash functions would make the passwords more secure... but apparently they don't. Why not?

I'm referring specifically to the section titled "Double Hashing & Wacky Hash Functions" in this blog post.

  • 7
    Bloggers have a tendency to click bait terms like "useless" when they actually mean "marginally less secure". – paj28 Jul 31 '16 at 11:45
  • "If someone gets their hands on a list of hashes and he doesn't know which hash functions were used" ... then it would help. But it would also be security through obscurity. To really evaluate it correctly, you would have to assume they do know the hash functions that were used. – Stijn de Witt Jul 31 '16 at 20:36
  • it's "useless" because there's no good reason to to do. – dandavis Aug 1 '16 at 3:05

The assumption always is, that any attackers will know the software used, including configuration like which hash is used. There is always a risk of that knowledge leaking, so robust systems must be safe even if their source is known. (Maybe the attacker bought the same piece of software) Also, if the attacker somehow obtains just one password, and the corresponding hash, it's relatively easy to find out which one of a set of plausible hash functions produces that hash.

As for using multiple hashes for one password at the same time, the problem is that it usually makes it possible to brute-force the hashes by just concentrating on the weakest or easiest to calculate (chosen by the attacker.)

There was no link, so I don't know exactly what situation it is you refer to, of course.

  • 8
    I believe that by "multiple hashes" the OP actually means doing something along the lines of: hash1(hash2(hash3(password))) not hash1(password) and hash2(password) and hash3(password). In this case I don't see a general way for the attacker to just "brute force" the easiest hash. Maybe studying the interaction between hashes makes it so that this triple hash is as weak as the weakest one, or maybe not... – Bakuriu Jul 31 '16 at 16:42
  • Recursively hashing (with one hash function) is how some of the stronger hashing schemes work, where the number of iterations can be increased as computing power improves. – Mark K Cowan Jul 31 '16 at 16:47
  • 7
    @Bakuriu, keep in mind that an attacker doesn't need to capture the real password -- they just need to find a plaintext for which hash1(hash2(hash3(plaintext))) is identical. So if one of your hash algorithms has a bug that reduces the keyspace, that makes the brute-force to find such a collision potentially easier. – Charles Duffy Jul 31 '16 at 18:46
  • As far as I understand, md5(md5(md5(plaintext))) is alot more secure than md5(plaintext), especially because you are more likely to find a rainbow table for the former. – programmer5000 Mar 7 '17 at 15:28
  • @programmer5000, maybe so, but triple-MD5 is still so light to calculate that a brute-force dictionary search of at least the most common/probable passwords is possible. Which is why they use algorithms (like PBKDF2) with many iterations of the underlying hash: to slow down brute-force guessing. – ilkkachu Mar 7 '17 at 19:49

Please see this related question on why it's a bad idea to combine multiple hash functions.

If someone gets their hands on a list of hashes and he doesn't know what the hash function is, how can the passwords be cracked?

It seems that you want to defend against the case that an attacker gained access to your database, but not to your source code. Stacking multiple known hash functions isn't a good approach for this though.

If an attacker can register an account themselves, they will have a combination of password and hash, making it rather easy to guess the used hash functions. Even if they do not have this, bruteforcing your combination of used hash functions will likely be easy.

So you don't actually gain anything by just combining some well-known hash functions, and writing your own from scratch is obviously a bad idea.

If you want an additional secret from your code base instead of the database, you may consider adding a pepper, which is not only more secure than combining hash functions, but also easier to maintain that some custom (combination) of hash functions.


It might not be completely useless, but perhaps it's a little too close to two very bad ideas - namely, security through obscurity and rolling your own crypto.

Ilkkachu mentioned above that we assume the attacker knows the specific implementation (Kerckhoff's principle). If this isn't the case, then we're tempted to rely on the specifics of our implementation for security, and this creates an additional weak point. Secondly, anything that goes beyond the standards designed by experts is risky, because it's very, very hard to be sure that you haven't added any vulnerabilities.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.