Is it a bad practice to use bcrypt(md5(pwd) + salt)?

Question

I'm trying to share logins between my app and an IPB forum.

I've seen that Invision is providing a module to share the credentials: IPS Connect

To make it simple, there is a master application and one or severals slave(s). The slaves are sending the credentials that the master need to store through an API.

The stuff is that for the register or login methods IPB is sending an md5 hash of the password. There is no way I'll store an md5 in my db so I was think to use bcrypt on the md5 hash doing something like

$storedPassword = bcrypt(md5(pwd) + salt);

What do you think about this alternative, is it a good practice to hash with bcrypt on top of a md5 hash?

Bad idea, hashing it multiple times increases chance of collision — Daniel Mensing, May 06 '13 at 13:59
I heard of it, but does it increase widely the chance of collision? — darkheir, May 06 '13 at 14:05
Two user can also have the same password before hashing it, so it doesnt realy matter for collision. And the chance of two user with a different password and the same md5 hash are close to nothing — Hugo Delsing, May 06 '13 at 14:13
@DanielMensing Just genuinely curious, what makes you think so? — likeitlikeit, Jun 04 '13 at 00:12

score 1 · Accepted Answer · answered May 06 '13 at 14:00

1

Although its perfectly fine to use $storedPassword = bcrypt(md5(pwd) + salt); in your application, security wise it has little benifit. Also it isnt needed to add your own salt to the encryption. bcrypt will take care of that internally and you dont need to save the salt anywhere.

An attacker targets the weakest link and if the other server just uses md5, they can attack that site to get the password and then it doesnt matter how strong you secured it.

But then again. Closing one door is still beter then leaving everything open.

answered May 06 '13 at 14:00

Hugo Delsing

13,803
5
45
72

Yeah but the other site won't store it, it will only send the password ( using md5) at registration or when the user tries to login. So for me the weak link would be sniffing the connexion between the 2 servers at the time the credential is sent. – darkheir May 06 '13 at 14:04
Then your approach is fine if you drop the salt. For all you care the user entered the 32 chars as their password themself. – Hugo Delsing May 06 '13 at 14:11
Why should I drop the salt? I think that it's that make the hash unique, no? – darkheir May 06 '13 at 15:00
If you add the salt, you also need to store the salt seperately in the database to be able to check for a valid password. bCrypt however has a built in salt. No need to add it. See http://stackoverflow.com/questions/6832445/how-can-bcrypt-have-built-in-salts or http://en.wikipedia.org/wiki/Bcrypt – Hugo Delsing May 06 '13 at 15:17

score 1 · Answer 2 · answered Feb 18 '16 at 15:04

This decreases security.

The MD5 hash usually shortens the password. This means an attacker only needs to iterate over the MD5 space. Even if you consider the MD5 space large, it is trivial to map a word dictionary into it. This simply adds no benefit, but potentially reduces the space.

Regarding collisions: You do not win the galactic lottery with bcrypt. With MD5, however, things are a tiny bit less certain, which is another reason to stay away from it.

You do not need to add a salt, bcrypt adds a good, unique salt by itself already. If you use bcrypt correctly, you never need to think about the salt.

It is a bit strange that your source only sends MD5 hashes. I would usually recommend to send the password (plaintext) over an encrypted connection:

If the connection is encrypted, it is secure to send it as plaintext.
If it is not encrypted, it does not matter if you hash the password first, an attacker can read if from the network anyway.

Is it a bad practice to use bcrypt(md5(pwd) + salt)?

2 Answers2