SHA1 vulnerabilities

Question

We are currently integrating with a third party component in our web application. Part of this integration requires sending data over http. This is done via POST parameters. An additional parameter is included in the request which is a SHA1 hash of the other parameters, plus secret key, combined as follows:

param1.param2.param3.param4.param5.param6.secretkey

A malicious user or man in the middle attack has access to the parameters and the output hash, but not the secret key which is not sent over http. I've been reading that SHA1 is considered weak and, with sufficient resources, broken. I'd like to understand more about the robustness of this setup and how SHA1 is weak.

My questions are as follows:

1. An attacker could iterate over all possible combinations of secret key, creating a new hash until a matching hash was found. Once the secret key is found, modifying the data (and then generating a new hash) sent between us would be trivial and, crucially, undetectable. Are there other ways (other than brute forcing) of finding out the secret key? Brute forcing could be used against any algorithm, leading me to believe there is a better/faster/cheaper way to do this. In other words, how do attackers exploit the weaknesses of SHA1?
2. If we are unable to get them to increase the security of their message by using SHA2 or SHA3, will a suitably long secret key with SHA1 protect us against any attacks?

Answer 1

You should read the this article. HMAC is the preferred option in any case. The way you use the keyed hash exposes you to all weaknesses of the hash algorithm. HMAC, however is still safe because its security relies on less strong assumptions on the hash algorithm.

Please note that the opposite way of computing the hash HASH(KEY || MESSAGE) (as opposed to HASH (MESSAGE || KEY) as you intend to do it) is considered completely insecure as you can read here and here.

Answer 2

SHA-1 is not generally broken for every kind of use case. But, it is considered that it provides insufficient protection against collision attacks which makes it unsuitable as a signature algorithm for example in certificates. It still is secure enough for use in HMAC though which is similar (but not equal) to your use case.

Thus I think that SHA-1 in your approach can currently only broken with brute force. Since SHA-1 is a hash designed to be fast you could harden your additional parameter by either using a longer secret or by using an algorithm which is designed to be slower. Both approaches make brute forcing harder since more time is needed by the attacker to try all possible secrets.

Additionally you should use a real HMAC as kaidentity points out in his answer because it is better to use something proven instead to invent your own, especially if cryptography is involved.

Answer 3

Knowing the parameters and not knowing the key vs. knowing neither does not make much difference in the case of large keys since any additional bit in the key will generate a completely different SHA. A small advantage may be for the attacker if he would knew the length of your secret additional key, but if that key is large enough you have no problem whatsoever. If the key is large enough brute force would be a futile attempt.

Answer 4

Researchers have now successfully executed a collision attack against SHA1, which is how MD5 died

Cryptographers refer to the attack disclosed Thursday as an "identical-prefix" collision, meaning it allows the attacker to create two distinct messages that have the same hash value. This variety is less powerful than the "chosen-prefix" MD5 collision carried out by Flame. In the latter case, attackers can target one or more existing files, such as the digital certificate that a company uses to authenticate its update mechanism. Despite the collision against SHA1 being less powerful, cryptography experts said any real-world identical-prefix attack represented a game-over event for a hashing function.

There is a website dedicated to the attack

It is now practically possible to craft two colliding PDF files and obtain a SHA-1 digital signature on the first PDF file which can also be abused as a valid signature on the second PDF file.

In other words, stop using SHA1

Answer 5

Depending on the implementation one thing that comes to mind is that you might be vulnerable to a length extension attack where an attacker 'starts' from your hash. I'm not sure this applies to you, but:

1. Your parameters are foo=1&bar=2
2. They are sent as foo=1&bar=2&sha(foo, bar, SECRET)
3. An attacker that wants to inject or replace a parameter could initialize their SHA hashing from foo=1&bar=2&sha(foo, bar, SECRET) and append their parameter

I did not go into technical details as I'm not sure it applies to you; also there are a few requirements (mostly, knowing the length of the original request) but I think those are satisfied from what I understand of your description.

Furthermore, your scheme is vulnerable to replay attacks: what happens if an attacker intercepts the transaction and replays it over and over? Since it's over HTTP that would be trivial.