Is it okay to wrap a cryptographic hash with MD5 for storage?

Question

Is there any security issues if you wrap your cryptographic hash with MD5 for storage purposes?

For example:

$hash = md5(hash($password,$salt,$rounds));

Note: hash() uses scrypt or bcrypt or pbkdf2 internally.

The only purpose of md5 is for storage since it only uses 32 bytes vs storing very long raw hash.

EDIT: Judging from the comments below I agree MD5 is not a good idea as it is collision prone but what if I use a better hashing function like SHA512? Still, comments below argue it may actually weaken it but can somebody please explain how?

How can this: $hash = SHA512(bcrypt($password,$salt,$rounds));

be weaker than this: $hash = bcrypt($password,$salt,$rounds); ?

It appears to me the former is stronger since you have to "crack" SHA512 first before you can even begin working on cracking bcrypt. Why others says otherwise?

Answer 1

You don't lose anything by applying MD5.

Since you use md5(hash()) as your combined hashing scheme, presumably the attacker doesn't have the ability to submit an input that is only evaluated by md5(); it's either evaluated by the whole scheme or nothing at all. So given a hash h in your database, the attacker's goal is to find m such that md5(hash(m)) = h. (m may or may not be the original password, since a collision password is good enough to allow them to log in fraudulently.)

Assuming the attacker obtained h and they were able to take advantage of a weakness in MD5 and find a pre-image h' such that MD5(h') = h, that doesn't help them since they then still have to find the pre-image of h' in hash. If hash is sufficiently strong in it's own right, this is no weaker than using hash by itself.

The gist of the idea here is that MD5 acts like a random map of inputs to outputs. MD5's mapping is well distributed and random strings don't generate collisions. Security-wise, MD5 makes it too easy to intelligently craft collisions, but we don't care about the the attacker intelligently crafting the input to MD5 in this case, we only care that by adding a mapping to the output of hash we don't create more collisions with MD5(hash()) than expected of hash by itself. In other words, you aren't relying on MD5's cryptographic collision-resistent properties here. You could add any sort of random-ish mapping to the output of a good hash function and, as long as that mapping isn't prone to accidental collisions, you should lose nothing.

Addressing the updated part of the OP: You can use SHA-512 and truncate the output. The recent FIPS-140-4 standard specifies truncating SHA-512 to a handful of lengths. This is a fully-endorsed method.

Answer 2

It is better to just truncate the original hash output.

First, mind the salt storage: in order to verify a password, you will need to recompute the password hash, using the same salt and iteration count. Some hash functions (namely bcrypt) traditionally encode the salt and iteration count in the output. If you just keep a hash of the bcrypt output but not the salt itself somewhere, you will not be able to recompute the hash from a given password, breaking functionality.

Then, password hashing works on preimage resistance. If the hash function you use is any good, then its resistance to preimages will be on the order of 2ⁿ with an output of n bits. Thus, you can truncate the output (the actual output bits, not counting the encoding of salt and iteration count, and disregarding any transformation of the bits into characters with hexadecimal or Base64) down to, say, 80 bits. If the hash function is any good, this will be robust enough. No need to rehash with MD5 or any other function; a simple truncate will do the trick. And if the hash function is not good and introduces weaknesses when thus truncated, then... why would you use it in the first place ?

(Collisions have nothing to do with the problem. Collisions are irrelevant to password hashing. Applying MD5 on the output would not induce any significant weakness, despite the non-resistance of MD5 to collisions, since password hashing is about preimages. But truncation is simpler, and "simpler" means "good" in security; it is also more flexible since you can choose the length as you see fit.)

Answer 3

Using MD5 in this case is fine, but you don't need to use MD5 to reduce the length of the hash string. Just perform a simple operation on the hash string to reduce it's length. For example, if your full length hash string is:

e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

You can trim it to whatever length is acceptable to you for storage, like:

e3b0c44298fc1c149afbf4c8996fb9242

Answer 4

I think that MD5(hash(password)) has no known practical weakness, if you need to truncate the hash to 16 bytes. Read B-Con's answer for the explanation. Note that this does rely on some properties of the MD5 function, not just on properties of the hash function. For example, suppose that it was discovered that the MD5 is actually not surjective (as far as I know, this is not known), and there are only N different MD5 digest values. Then finding another hash with the same MD5 would be a matter of computing the hash of N different passwords, which might be workable if N is not too large.

However, if you do that, you will be guilty of rolling your own crypto. Do not roll your own crypto.

Fortunately, there's a better way to obtain a 16-byte value from a hash function that's still a hash function. With a good hash function, each bit is as independent as possible from the other bits and doesn't reveal any information about the hash. Therefore, if you take 128 bits from a hash, you get a 128-bit hash. For the SHA family, this is officially accepted (FIPS 180-4 §7): if you want an N-bit hash, you can take an approved hash function with that produces more than N bits and truncate to the first N bits. The NIST recommendations for using hashes (§5.1) discuss the strength you can expect from an N-bit truncation.

If you're doing this because you have a fixed-size database field that was intended for MD5 digests, keep in mind that while it is acceptable to truncate the digest, the salt is non-negotiable. You must have a unique salt, and it has to be stored in the database somehow. Each user's salt should be distinct both from any other user's salt and from a salt used in any other database. (Salt collisions can be tolerated if they're infrequent enough, but if two users happen to have the same password and the same salt, that will be obviously visible.) The salt can be generated from other fields, but it isn't a good idea, because it's hard to achieve unicity; see Primary Key as Salt?. Other background on salt: What should be used as a salt? How to store salt? Why is using salt more secure?

Answer 5

Whilst there aren't any explicit attacks I'm aware of against such a thing, I don't recommend it. MD5 is broken, and has many known collisions. As such, an attacker might be able to generate inputs such that the output of the KDF is a collision with another password.

Instead, why not use a KDF such as PBKDF2 with a tweakable output size?

Answer 6

Yes, there is an issue.

The resulting MD5 hash is just that. A MD5 hash. It would be prone to collision attacks against it.

MD5 is a hash function with known collision vulnerabilities. Avoid using it if at all possible.