I am reading the documentation for Kentico where it describes using hashes to validate query strings


Documentation https://docs.kentico.com/display/K8/Query+string+hashing

I am making an assumption: On it's own hashing a query string and including it as part of the string is not useful. Anyone who knows the algorithm (published int he help doc)could simply generate the hash from his new malicious query-string, and include it as part of the request.

The added protection that Kentico uses is a static salt that is included when hashing the query-string. This should make generating your own hash not as simple.

My question is how difficult would it be to solve this salt? An attacker could easily generate many different query strings They would know the input, the output, and the algorithm. Could they simply figure out the salt?

And if they know the salt, can they then without any difficulty generate their own query-strings?

1 Answer 1


Cryptographic hashes are in principle not reversible. So it should not be possible to get the salt by taking a known query string and associated hash (or a set of them) and reversing them, other than by trying brute-force. Brute-force is not going to be feasible with a random GUID that's has 32 hex-characters (one hex character is 4-bit, hence the GUID is 128 bit). So brute force of the salt should require creating ~2^128 sha-2 hashes to be created (half the time you should find it with 2^127 or less hashes). On the other hand, if you used a 2 hex-character-salt, brute-forcing would be trivial with only 2^8 = 256 SHA-2 hashes.

Granted this analysis assumes no new unpublished attacks on SHA-2 exist or one that utilizes this expanded attack surface by being able to create multiple hashes of arbitrary text all starting with the same salt. This scenario seems a bit similar to the related-key attacks where you break a cipher (find the decryption key) when you are assisted by being able to force someone to encrypt data with several unknown keys that are related in some mathematical sense (some bits vary but most are the same).

However, I'm not aware of any such attack on SHA-2 or any other hash and have never seen the problem actively discussed -- given everything but s in the following "H(s ++ p1) = h1, H(s ++ p2) = h2, ..., H(s ++ pN) = hN)" recover s. Typically you think of three attacks in regard to hash functions; pre-image resistance (given h generated by H(m) find m), second pre-image resistance (given m1 find another m2 such that H(m1) = H(m2)), and collision resistance (find any two distinct m1, m2 such that H(m1)=H(m2)). This is something different.

Personally, I can't imagine how an attack of this type would work on a modern cryptographic hash like SHA-2 (with 64 rounds) due to the avalanche effect, but to quote Schneier's law "Any person can invent a security system so clever that he or she can't imagine a way of breaking it." The fact that it hasn't been studied extensively would not make me confident that hash functions would be resistant to this type of effect against very sophisticated attackers.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .