MD5 is never an acceptable way to protect passwords

[jlawton]

Even on "insecure" sites, most people generally re-use passwords they use elsewhere. Please don't encourage anyone to use MD5 to protect passwords. Not only will this not really protect a password, it doesn't protect against replay attacks, etc.

The gain from this use of MD5 is very very small. Enough people will misuse this without your suggestion.

Q.md5 - to one-way-encode passwords etc. in insecure websites before sending to the server

[EGreg]

You are most likely right. I should explain instead that the md5 should be used to verify HMACs sent by a service.

However, when sending passwords over the wire, the client should ideally hash it and the username/email + id of the provider should be used as the salt. That way different providers can't impersonate a user on each other's servers. This salt SHOULD be applied on the client side even if you are using https, or you are actually trusting the provider to not misuse or leak your password, e.g. in logs. See for example http://blog.cloudflare.com/cloudflare-prism-secure-ciphers

Gregory Magarshak
Qbix

On Jul 16, 2013, at 4:07 PM, jlawton notifications@github.com wrote:

Even on "insecure" sites, most people generally re-use passwords they use elsewhere. Please don't encourage anyone to use MD5 to protect passwords. Not only will this not really protect a password, it doesn't protect against replay attacks, etc.

The gain from this use of MD5 is very very small. Enough people will misuse this without your suggestion.

Q.md5 - to one-way-encode passwords etc. in insecure websites before sending to the server
—
Reply to this email directly or view it on GitHub.

[jlawton]

I'm assuming Q will be used on the front end here.

The trouble is, most people build both the client and server side of an app, so if you can't trust the server, you can't trust the client, which does get your plaintext credentials. If the user can't trust you to handle their password, why would they give it to your JS front end?

If you're worried about the NSA snooping on your SSL protected channel, you may indeed want to avoid sending passwords, but there are better schemes than MD5 in that case, as you can assume the attacker is quite sophisticated.

If you want to verify HMAC or hash passwords, you provide an HMAC function (which takes a salt). Even then, I'm not sure how useful this is on the client (without a secure channel). You still have a replay problem for passwords, and the HMAC shared secret is known to an attacker if they can see your JS in plaintext, so it should be easy to generate fake service responses. You have stopped them naively using rainbow tables, though.

A nonce can help against replay attacks, but the problem there is that the server probably needs the plaintext password to verify the challenge response, so you usually have to implement SSL for your signup form anyway.

Overall, it's much easier to gain the illusion of security than to gain actual security. I think it's best not to give people ideas which will lead to misuse.

[tadman]

+1 MD5 is completely useless from a cryptographic perspective and has no business being in a library. It will just give people bad ideas and undoubtedly lead to pain, suffering, and misery.

If you want security, use SSL (TLS). Do not depend on flimsy functions like MD5.

[EGreg]

We use it at the company to hash the password before sending it to the server, even with an https connection, to minimize the fallout from password reuse. As a salt we use provider_id+user_id. We also use md5 to verify some basic HMAC for stuff from another provider signed with a session secret.

But maybe it has little place in the open sourced version.. because as jlawton said, it's much easier to gain the illusion of security than to gain actual security, and we shouldn't lead people in the wrong direction by including Q.md5 in the library.

On Jul 17, 2013, at 3:04 PM, Scott Tadman notifications@github.com wrote:

+1 MD5 is completely useless from a cryptographic perspective and has no business being in a library. It will just give people bad ideas and undoubtedly lead to pain, suffering, and misery.

If you want security, use SSL (TLS). Do not depend on flimsy functions like MD5.

—
Reply to this email directly or view it on GitHub.