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.

  • 8
    Bloggers have a tendency to click bait terms like "useless" when they actually mean "marginally less secure".
    – paj28
    Jul 31, 2016 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. Jul 31, 2016 at 20:36
  • it's "useless" because there's no good reason to to do.
    – dandavis
    Aug 1, 2016 at 3:05

3 Answers 3


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.

  • 10
    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, 2016 at 16:42
  • 1
    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. Jul 31, 2016 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. Jul 31, 2016 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.
    – user136535
    Mar 7, 2017 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, 2017 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.

  • "Even if they do not have this, bruteforcing your combination of used hash functions will likely be easy." Can anyone elaborate on this? Its difficult to brute force data transformations when they are of the nature of column1*column2/(column1+column2). Cryptographic functions are vastly less simple. I doubt reverse engineering of code/data would be this difficult if deducing arbitrary compositions of hashes was so trivially easy.
    – Milind R
    Nov 23, 2021 at 21:18

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .