14

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.

Community
  • 1
ninesalt
  • 250
  • 2
  • 6
  • 8
    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 01 '16 at 03:05

3 Answers3

12

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.

ilkkachu
  • 2,106
  • 1
  • 11
  • 15
  • 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 '16 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. – 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. –  Mar 07 '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 07 '17 at 19:49
  • "if the attacker somehow obtains just one password"... so you are saying, before hacking a website, it is always a good idea to have at least one account there for which you have chosen (or generated) the password? – NH. Oct 17 '17 at 19:00
8

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.

tim
  • 29,122
  • 7
  • 96
  • 120
  • "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 '21 at 21:18
3

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.

tao_oat
  • 312
  • 1
  • 2
  • 10