Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am creating a page on a website that will show a user some authorized information from another website, and that website uses a combination of the user's user-number and a secret passphrase hashed using md5 and sent over an [edit] HTTPS POST request. Is this unsafe?

Note: I am not involved in the decision making for what security procedures to implement. I am simply connecting to a 3rd party site that uses this system and I wanted an assessment of their security.

share|improve this question
What i recommend "Don't Reinvent the Wheel" go for single sign on services such as Shibboleth – Ali Ahmad Feb 5 '13 at 9:49
MD5 is weak compared to other hashing algorithms. If you're going to transfer any sensitive data, i'd reccomend doing it over SSL/TLS to reduce the chances of anyone capturing and attacking the MD5 – NULLZ Feb 5 '13 at 10:06
MD5 should not be used authenticate a user and should not be connected to any user data. – Ramhound Feb 6 '13 at 13:13
If the password is of >128 bits entropy, you're fine. Also, this might be of interest: – Henning Klevjer Feb 8 '13 at 6:30

This idea raises red flags in my head for a few reasons:

  1. MD5 is broken in a way that makes it possible for an attacker to compute a colliding hash, such that md5(a + b) == md5(a + c) without having to know b. In this case, a is your user ID, and b is your secret. As such, MD5 is is a bad choice here. SHA family hashes are also a bad choice, because they rely on the same construction and suffer the same issue. Update: No, I got this wrong. MD5 isn't quite as broken as I thought. Regardless, the following points hold true...
  2. If you're relying on MD5 for brute-force resistance, you're going to have problems. MD5 runs way too fast for that kind of thing. You need to use a slow KDF such as PBKDF2 or bcrypt. Even so, this seems like an odd use for a hash or KDF.
  3. The salt seems to serve no purpose here. Salts are used to prevent precomputation attacks such as rainbow tables and hash databases. If the goal is to prevent replay attacks, the salt will not help you here. An attacker will be able to replay your authentication messages.
  4. An attacker can modify the request in-transit, by performing a man-in-the-middle attack. In doing so he is free to arbitrarily alter these messages.

The only way to properly do this is to use HTTPS (i.e. TLS) for the connection. This provides authenticity and confidentiality, and prevents replay attacks.

share|improve this answer
md5(a + b) == md5(a + c) The attacker won't be able to find such a collision, unless he knows all of a, b and c, and he chose part of both b and c himself. He won't be able to find such message pairs at all for SHA-2. Your claim is even stronger, since you say the attacker doesn't need to know b, so he doesn't just need to find a collision, he needs to find a second pre-image. We don't know how to do that for md5. – CodesInChaos Feb 5 '13 at 11:54
I suspect you were talking about length extensions, but those don't allow you to find collisions. They only allow you to figure out a message extension m1 for which you know hash(k+m0+m1) if you know hash(k+m0). But that hash differers from the original hash. Length extension is dangerous if you use hash(k+m0) as MAC. – CodesInChaos Feb 5 '13 at 11:56
@Polynomial: if you can do your point 1, then you know how to break preimage resistance of MD5, and you should publish an article. Alternatively, change that to the following: given md5(a), it is possible to compute md5(a+b+c) where b depends only on the length of a, and c can be chosen arbitrarily -- and this can be done without knowing a itself (only its length). – Thomas Pornin Feb 5 '13 at 11:57
Whoops, my bad! – Polynomial Feb 5 '13 at 12:26
Thanks for the info. I was mistaken, the POST request I believe goes over HTTPS...or at least the url the POST request is made to begins https:// – michaelrbock Feb 8 '13 at 4:53

Does the user ID or the passphrase expire after a single use? If not, what would prevent an attacker from re-using the MD5 hash (or any hash) of that information to make a different request? Why even bother hashing it at all? Answer: No, it is not secure.

share|improve this answer
"Why bother hashing at all?" - So the man in the middle does not know the password itself. Yes, it would not add security for this particular instance, but it helps prevent others from seeing the user's password and thus their privacy and even security in a greater sense. Most people re-use passwords or parts of passwords. Allowing attackers to be able to see any user password ever, can be extremely dangerous. – Domi May 8 '15 at 10:15

Generally speaking, I would say no.

You are relying on this property: An attacker knows Y and Hash(X+Y) but doesn't know X. He must not be able to determine H(X+Z) for any Z not equal to Y.

The problem is, MD5 does not have this property and was not designed to resist this type of attack. In fact, no Merkle–Damgård hash can resist this kind of attack.

The Flickr API assumed MD5 had this property was decimated by an attack of this kind.

share|improve this answer

As you describe it, things go the following way: your Web site needs to forward a request to another Web site, and the latter will accept only if the request comes with an "authentication blob" which happens to be the hash of a user identifier and his password. This blob (the MD5 result) is then "the password" since showing it is sufficient to grant access; this is very weak with regards to eavesdroppers, since spying on the line would be sufficient to recover the blob, at which point the attacker could attach it to whatever requests he would like to send.

If the protocol is not as described above, but ties the hash to the requested data (e.g. the hash is not computed over the user ID and passphrase alone, but also on the path of the requested data), then the authentication is a bit less weak, but still not good; It would exhibit the two classic sins:

  1. Eavesdropping reveals a hash value computed over the passphrase and some known data, allowing for an offline dictionary attack: the attacker just "tries" some potential passwords until a match is found with the observed hash. Since a 150$ GPU can compute billions of MD5 instances par second, even medium-strength passwords won't resist the onslaught for long.

  2. The whole communication is unprotected, so eavesdroppers will observe the data itself (the data for which access authentication was used, so presumably sensitive data). Active attackers will be able to manipulate request and response in arbitrary ways.

Redemption is achieved with the use of SSL, which fixes both issues.

share|improve this answer
So if the POST request is made over HTTPS, then it's safe? – michaelrbock Feb 8 '13 at 4:56

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.