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:


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?
  • Since you mention a secret key, am I right in the assumption that you are actually using an HMAC-SHA1 message authentication code and not just a plain hash value?
    – mat
    Nov 4 '16 at 8:15
  • It is a straight SHA1 hash of the publicly transmitted request data and private secret key. I don't believe HMAC is involved here but could be wrong. Nov 4 '16 at 8:21
  • So it's not really a secret key but actually just a (secret) salt for the hash. Is there a particular reason why you are not using the HMAC construction, which would give you exactly what you want and is more secure than your construction.
    – mat
    Nov 4 '16 at 8:30
  • 1
    Possible duplicate of Why is SHA1 considered less secure than often necessary?
    – KanekiDev
    Nov 4 '16 at 8:32

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.


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.


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.


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


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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