Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have token made as sha256("public text" + "secret value"), or any number of such tokens with the same "secret value" but different "public text". sha256 that is used is not salted - so that sha256-ing the same text will always produce the same hash.

Can I construct a valid token with my own "public text" (or even reveal the secret) without exhaustive search for secret?

share|improve this question
You may be able to perform a variation on a length extension attack (, but by pre-fixing the data rather than suffixing. Without thinking about this in depth, I couldn't say for certain, but it seems reasonable at first glance. – Tinned_Tuna Jul 16 '13 at 13:59
up vote 5 down vote accepted

The length extension attack that @Tinned_Tuna talks about would have allowed you to generate forged tokens with a "public text" of your own choosing (within some format constraints due to SHA-256 padding, though), but only if the secret had come first in the hash function. By inputting the secret last, this specific weakness is avoided.

Another, less serious weakness related to the input of the "public text" first is that, potentially, as an attacker, you could try to build a SHA-256 collision, have one message of the colliding pair be authenticated by the key-owner system, and the hash value will be valid for both messages. In other words, using SHA-256(public+secret) makes the algorithm only as strong as collision resistance of the hash function, instead of preimage resistance. This is not a serious problem because SHA-256 has a 256-bit output, which makes it immune (in practice) to collisions; that's more a theoretical issue in that you do not get your money worth (you have to use a 256-bit output to get 128-bit security).

An handwaving way of stating things is that, in such constructions, you need to input the secret key at least twice, at the beginning and at the end of the computation. But, really, you want a MAC; that's what your "tokens" are about. So, do yourself a favour, don't try to invent your own algorithm; instead, use something which has been carefully designed and studied for years, even decades, and provides the kind of security you want. This is called HMAC. HMAC uses an underlying hash function (e.g. SHA-256) but does it well, with the secret key inserted at the right place so as to avoid the tricky pitfalls implied by using an actual hash function, as opposed to the mythical beast known as a "random oracle". If you study HMAC, you will see two nested invocations of the hash function, with the secret key used twice.

share|improve this answer
Thanks for the response - actually what I'm trying to do is to get some arguments against implementing our own algorithm. – Ivan Sopov Jul 16 '13 at 14:34

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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