Why improvising your own Hash function out of existing hash functions is so bad

Question

I'm afraid I'll have tomatoes thrown at me for asking this old question, but here goes.

After reading that cooking up your own password hash out of existing hashing functions is dangerous over and over again I still don't understand the logic. Here are some examples:

• md5(md5(salt) + bcrypt(password))
• scrypt(bcrypt(password + salt))
• sha1(md5(scrypt(password + md5(salt))))

The typical arguments against these go as follows:

You're not a cryptographer! You've got no idea if these hashes are more secure. Leave it to the experts who know what they're doing. These add no extra security.

Granted they don't improve the function as a hash (i.e. make it harder to reverse or find collisions etc.), but surely surely they don't make it worse as a hash? If they did then hackers would be able to re-hash standardly hashed passwords into these wacky hashes as they see fit and weaken the hash? I don't buy it.

Second argument:

Kerckoffs's principle: A cryptosystem should be secure even if everything about the system is known.

Agreed. This is basically the motivation for not storing your passwords as plaintext in the first place. But if my response to the first criticism stands then these wacky hashes still function as secure hashes, and our system doesn't break Kerckoffs's principle anymore than it would with a standard hash.

Here are two possible (and worthwhile, as far as I can see) advantages to using a "wacky" hash over a normal hash:

1. Sure, your system should be secure if the attacker has the source code, but it's a very likely possibility that your attacker wont have access to your source code and probably won't be able to guess your wacky hash, making any attempt at a brute force impossible.
2. (This one is the real motivation behind me asking this question) BCrypt is thought to be secure, hard for the CPU and GPU (great) but can be very fast with specialized hardware. SCrypt is said to be hard to bruteforce on CPUs, GPUs and currently available specialized hardward but is more recent and not trusted by the cryptographic community as much as BCrypt due to the lack of exposure it's had. But doesn't the hash BCrypt(SCrypt(password + salt)) get the best of both worlds?

I appreciate that the passion/anger behind most rants against these home-brewed hashes comes from the average programmer's lack of knowledge of what makes a good hash, and a worry that encouraging this sort of wacky-hashing will inevitably end up with weak and useless hashes getting into production code. But If the wacky hash is carefully constructed out of solid and trusted hashes, are the gains in security not very valuable and real?

---

Update

I got a bunch of good answers on this, thanks. What I seemed to be overlooking in my assumptions was that, although combining hashes can't make it easier to crack the original password and therefore crack the constituent hashes, the combination of two or more secure hashes can - at least in principle - be weaker than any one of its inner hashes due to the unstudied and complex interactions between them. Meaning it could be possible to find some string that got past the wacky hash without necessarily breaking the hashes that made it up.

Answer 1

The fact that you need to ask this question is the answer itself - you do not know what is wrong with stacking these primitives, and therefore cannot possibly know what benefits or weaknesses there are.

Let's do some analysis on each of the examples you gave:

md5(md5(salt) + bcrypt(password))

I can see a few issues here. The first is that you're MD5'ing the salt. What benefit does this give? None. It adds complexity, and the salt is simply meant to be unique to prevent password collisions and pre-computation (e.g. rainbow table) attacks. Using MD5 here doesn't make any sense, and might actually weaken the scheme since MD5 has known trivial collisions. As such, there is a small possibility that introducing MD5 here might mean that two unique salts produce the same MD5 hash, resulting in an effectively duplicated salt. That's bad.

Next, you use bcrypt on the password. Ok. Well, most bcrypt implementations require a salt internally, so this is already technically invalid. Let's say you know that, and you meant to say bcrypt(md5(salt), password). This part is still falling to the weakness I described above, but it's not too shabby - remove the MD5 and it's a standard use of bcrypt.

Finally, you MD5 the whole thing. Why are you doing this? What is the purpose? What benefit does it bring? As far as I can see, there is no benefit at all. On the detriment side, it adds more complexity. Since most bcrypt implementations use the $2a$rounds$salt$hash notation, you're going to have to write code to parse that so that you can extract the hash part and store the rest separately. You're also going to need an MD5 implementation, which was unnecessary.

So, in terms of code footprint for potential attack vectors, you've gone from a simple bcrypt implementation, to a bcrypt implementation with custom parsing code, and MD5 implementation, and some glue code to stick it all together. For zero benefit, and a potential vulnerability in salt handling.

Next one:

scrypt(bcrypt(password + salt))

This one isn't too bad, but again you need some code to parse out the results of bcrypt into hash and salt / round count separately. In this case I'd guess that there is a slight benefit, because bcrypt and scrypt work in different ways for roughly the same goal, which would make it a little more difficult for an extremely well-funded attacker to build custom ASICs to break your scheme. But is that really necessary? Are you really going to hit a situation where a nation state will devote a few million dollars to just to break your hash? And, if that case ever arises, will it really bother the attacker to have to spend a few extra million to double their chip count?

Another potential issue with combining bcrypt and scrypt like this is that there has been very little study into how the two interact. As such, we don't know if there are any weird cases that can cause problems. As a more obvious example, take the one time pad. We compute c=m^k for some message m and some equally long perfectly random key k, and we get perfect security. So let's do it twice, for even more security! That gives us c=m^k^k... oh, wait, that just gives us m. So because we didn't take the time to properly understand how the internals of the system worked, we ended up with a real security vulnerability. Obviously it's more complicated in the case of KDFs, but the same principle applies.

And finally:

sha1(md5(scrypt(password + md5(salt))))

Again we're running into the MD5'ed salt issue. I'm also intrigued by MD5'ing the SHA1 hash. What possible benefit could that have, if you're already using a slow KDF like scrypt? The few nanoseconds it would take to compute those hashes pales in comparison to the hundreds of milliseconds it would take to compute the scrypt digest of the password. You're adding complexity for an absolutely irrelevant layer of "security", which is always a bad thing. Every line of code that you write is a potential vulnerability.

---

Now remember that point I made at the start of my answer. If, at any point in this answer, you thought "oh yeah, I didn't think about that", then my point is proven.

You're running into what I would describe as Dave's false maxim:

If I add more crypto things, it will be more secure.

This is a common trait among developers, and I once believed it too. It goes hand-in-hand with denial of other principles, such as Kerckhoff's Principle. Ultimately, you have to realise and accept that obscurity isn't a safety rail; it's a crutch for weak crypto. If your crypto is strong, it needs no crutch.

Answer 2

Crypto primitives can be stacked safely, and increase security if, and only if, you know the primitives well enough to understand their weaknesses and how those weaknesses interact. If you don't know them, or don't understand the details - well, that's how you get Dave's protocol.

The problem is very few people know them all well enough to judge if a certain combination is safe. Which is why it needs to be something that is published and reviewed, if it's not been reviewed you have no way of knowing if it's as strong as scrypt or if it's closer to CRC32.

So, if you aren't an expert - it's quite possible that you have something weaker than the weakest primitive you've used (see Dave's protocol) and you wouldn't know it. Or at least you wouldn't know it untill it's cracked – finding your users' passwords on Pastebin isn't quite the ideal way to determine the scheme is flawed.

I do agree that some degree of obscurity can help from a defense in depth perspective, but the underlying system must be secure.

Between scrypt, bcrypt and PBDKF2 - at least one of them will be supported on pretty much every platform. These are known and well tested - they offer differing levels of protection, but they are still far more secure than a bizarre stacking of md5 and sha1.

Answer 3

For your specific question of combining scrypt and bcrypt, remember that these functions have a configurable cost, and you want to raise that cost as much as possible, while keeping it tolerable for your specific usage. For instance, if you can use bcrypt with up to X iterations (beyond which it is too expensive for your server and your average number of user connections per second), or scrypt with up to Y iterations, then you cannot use scrypt(bcrypt) with X iterations for bcrypt then Y iterations for scrypt: this will be beyond your CPU budget.

Thus, if you cascade scrypt and bcrypt, then you must use both with less iterations than what you could have done with one alone. You don't "get the best of both worlds" by simply stringing them together. In fact, the best you can hope for is a kind of average between the two. And that comes at the price of more complex code, something which is inherently bad when talking about security (or, for that matter, maintainability).

Answer 4

In addition to Adam's answer, I'd like to also mention that any time you use cryptography, you should have a strong and unavoidable reason to do so. In your examples above, this does not exist.

md5(md5(salt) + bcrypt(password))
scrypt(bcrypt(password + salt))

The bcrypt and scrypt algorithms are already strong enough, and considered effectively unbreakable. What problem are you trying to solve? And why do you believe that combining their results (particularly with md5) will solve it? In the best case scenario, you've likely merely reduced the difficulty of cracking the password to that of the weakest hash, rather than actually improving security. And the worst case scenario is frighteningly undefined.

md5(sha1(md5(md5(password) + sha1(password + salt)) + password))

This solution is even worse. It manually implements a repeated hashing scheme, but without enough rounds to actually impose a significant work factor on attackers.

In a nutshell, the problem is that:

• you're throwing around cryptography without actually having a problem that needs solving
• you've dramatically increased the likelihood of introducing flaws in your implementation
• you've likely decreased security to the weakest of the hashing algorithms, and
• you've introduced an unknown worst-case scenario where none used to exist

Answer 5

If you apply unsafe operations to a secure algorithm, you can definitely break the hashing function. Your new function could even be far worse than the weakest link.

Why don't attackers use this to break secure functions? It doesn't help them. For example, if I overwrite the first 440 bits of a password safely stored using bcrypt with zeroes, I can easily find a matching password by brute force, but that password will only work on my own terrible algorithm. A sane implementation would probably reject it.

Zeroing large chunks of a hash is clearly bad, but even safe operations can be combined into something dangerous. Adding two numbers (modulo n to ensure a constant length) is 'safe'. Generally, no entropy is lost. Still, h(x) + h(x) mod n reduces the quality of the hash h(x) by one bit, as the result is always even. The equally safe operator XOR does even worse, as h(x) XOR h(x) always returns zero.

These pitfalls are fairly obvious, but not all of them are. Keep in mind that, as always, it is trivial to invent a scheme good enough that you won't find any weaknesses yourself, but very difficult to invent one where no one else can.

Answer 6

Hash functions are built by cryptographers and destroyed by cryptographers. There are many strong hash functions as well as weak ones still being use today. Programmers should trust the cryptographers and the hash function. If there was ever a vulnerability in the hash function, then you would surely hear about it on the internet or through co-workers and then cryptographers will surely to a deep investigation. With any secure hash algorithm, it's only known weakness may be a bruteforce attack.

Combining hash functions adds almost no extra security and anything you might want to add, is probably already implemented in the function already.

Salting a password is great for reducing the effectiveness against rainbow tables such that a password couldn't be just "looked up." Whether you hash a function twice or change the hash function, it is essentially salting the password. And most functions include an easy method to salt so there is really no need to implement this.

Lets say I want to create my own secure hash because everyone does it. And since I'm not a cryptographer, I will need it "really" secure, because of course, every programmer knows how to make a secure hash instead of using the secure ones already created. So I create my devious hash function, mod10(md5(sha1(bcrypt(password + salt)))).

As you can see from my hash function, it is really secure because I use so many different things in it. Of course in this silly example, it is easy to see there are only going to be 10 different possible outputs. But by simply using a single secure hash function, it would have completely avoided this.

Sure, your system should be secure if the attacker has the source code, but it's a very likely possibility that your attacker wont have access to your source code and probably won't be able to guess your wacky hash, making any attempt at a brute force impossible

So we are assuming an attacker got ahold of the database table that contains the hashes. I would assume it would be very likely that an attacker can get the webpage files aswell. Your systems running these services maybe the same exploit that allowed you database to get taken. A database server is setup so that that public cannot directly access it. On the other hand, your web server containing your code, is on the front lines.

Answer 7

Anytime you increase the complexity of an algorithm or even add more lines of code, you increase the points of failure in your application. There may be unintended consequences of combining algorithms. This may lead to certain tells or other signs which can actually weaken the cryptographic strength of the system.

The more libraries you use in your application, the greater the risk to your application in general. If a flaw is found in one implementation that allows a weakness, code execution, etc. then your application is vulnerable. If you happened by luck to select another algorithm that was not attacked, your safe for the time being (of course you could also be on the unlucky side of luck).

Remember KISS: Keep it simple, stupid, or else you may get lost in the complexity.

Answer 8

I am going to disagree with a whole bunch of people who are smarter than me and more experienced in security than I am. So I am probably wrong.

Improvising your own hash function is a good idea - if you do it right. Follow these 3 simple steps.

1. Identify a weakness or flaw in the existing hash functions.
2. Improvise your own hash function that does not have this flaw.
3. Verify that your improvised hash function has all the strengths of the existing hash functions.

After you complete step 3, you would be a fool not to use your improvised hash function.

Answer 9

When concatenating different hash functions because you are worried the one it is vital that you apply the salt back before applying the next hashing algorithm, then any collision weaknesses in one of the algorithm won't taint the second hash function that you are using:

scrypt(bcrypt(password + salt) + salt)

But I think scrypt is an established technique now, Argon 2i has won the password hashing competition and is believed to be more secure and bcrypt has been around a long time and has proven to be secure against trivial bypasses.

Therefore the following would make more sense, and would combine the strength of argon 2i, but would fall back to bcrypt if a future attacker showed how to trivially break argon 2i, which is currently thought to be hard:

bcrypt(Argon2i(password + salt) + salt)

But you are less likely to make a mistake if you simply do:

scrypt(password + salt) Or bcrypt(password + salt)

Remember, most breaches are due to human error in the code, much better to keep it simple and thoroughly review your code with dynamic, static analysis and human code reviewers, to make sure no sql injection attacks slip through (Remember always parameterize your database queries!)

Answer 10

I have learned a lot with this thread, so I thought in a way to easily understand the possible outcome when combined different methods (of course, it won't fit all cases):

[W=weak, S=strong]:

Formula        | Example
---------------|-----------------
W(W) = W       | md5(sha1(pwd))
W(S) = W       | md5(bcrypt(pwd))
S(W) = W       | bcrypt(md5(pwd)) 
S(S) = S-      | bcrypt(scrypt(pwd)) //their interaction is unknown
W+S = W        | md5(pwd)+brcypt(pwd) 
S+S = W        | bcrypt(pwd)+scrypt(pwd)
W'+S" = S      | md5(pwd1)+brcypt(pwd2) //pwd1 != pwd2
S'+S" = 2S     | bcrypt(pwd1)+scrypt(pwd2) //pwd1 != pwd2
SUBSTR(W) = W  | substr(md5(pwd),n); //Shorter the string, the weaker
SUBSTR(S) = S- | substr(bcrypt(pwd),n); //Shorter the string, the weaker
S+x = S+       | bcrypt(pwd)+x   //x=Variable str. unrelated to pwd
S(S+x) = S-    | bcrypt(scrypt(pwd)+x) //x=Variable str. unrelated to pwd
ROT13(S) = S   | ROT13(bcrypt(pwd))  

What I want to achieve here is to show in a simple way that those combinations won't add extra security in most of the cases (so added complexity is not worthy).