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.

What i recommend "Don't Reinvent the Wheel" go for single sign on services such as Shibboleth
–
Ali AhmadFeb 5 '13 at 9:49

1

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
–
NULLZFeb 5 '13 at 10:06

MD5 should not be used authenticate a user and should not be connected to any user data.
–
RamhoundFeb 6 '13 at 13:13

4 Answers
4

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...

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.

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.

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.

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.
–
CodesInChaosFeb 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.
–
CodesInChaosFeb 5 '13 at 11:56

1

@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 PorninFeb 5 '13 at 11:57

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.

"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.
–
DomiMay 8 at 10:15

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:

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.

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.