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.
This idea raises red flags in my head for a few reasons:
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.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.
Feb 5, 2013 at 11:54
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.
Feb 5, 2013 at 11:56
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).
Feb 5, 2013 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.
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.
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.
Redemption is achieved with the use of SSL, which fixes both issues.
