# Is it a bad idea to make multiple SHA-* with the same header?

I'm trying to figure out a simple way to verify ownership over a short period of time (typically 8 - 24h), to be used in a mobile application.

One of the ideas I came up with is to hash the following concatenated sequence:

user pincode + user unique ID + payload
where
pincode   is a 6 digit passcode, provided by user
unique ID is a GUID identifying the device, generated once


Provided I'm using an algorithm like SHA-512 or similar, what's the risk of using always the same header (pincode + ID) for multiple hashes?

Is it easier for an attacker to figure out a header if used for multiple hashes?

Optionally, do you think this would be a valid ownership verification, knowing an attacker could potentially replicate a payload.

• Why not simply SSL? – CodesInChaos Mar 10 '17 at 16:58
• What do you mean by ownership? – CodesInChaos Mar 10 '17 at 17:28
• I think you may need a challenge-reponse protocol or something similar, e.g. include a challenge in the hash. Warning: PIN codes are notoriously hard to store (creating a hash table is not going to impress anyone) and you would need to store the PIN in any challenge response protocol. – Maarten Bodewes Mar 11 '17 at 0:15
• @CodesInChaos You may be right actually, I could simply return a token generated server side, and store that in the app. That wouldn't be less secure than a cookie (or would it?). – aspyct Mar 14 '17 at 8:23
• Use a keyed hash like HMAC instead of the raw hash. And if your pin is too short there is no way it will last 24h of brute force. That calls for more than 64Bit as the secret. The unique ID would add to that if you keep it secret. – eckes May 10 '17 at 20:21

The standard assumption in cryptography is that the adversary knows

• methods used
• what's physically transmitted (here, I guess payload and the SHA-512 hash);
• any data other than the key(s)

Here pincode is clearly a key, and the default assumption would be that unique ID is not. With this hypothesis, a single hash is enough to allow an adversary to find pincode by enumeration, then break the system. Thus multiple hashes are not worrying, but the basic principle is insecure.

Additionally, SHA-512 is vulnerable to a length-extension attack, and with a few hypothesis about what's admissible as payload, that might allow computing the hash for an extension of the payload, without knowledge of unique ID (or even the original payload; only its length is required).

If some other hypothesis applies, please edit the question.

As long as the three inputs are random, and in total longer than 80bits then the hash values are good to go. If your randomness only provided by the 6 digit pin, breaking ur auth is as secure as brute forcing 6 digit password.

• Why longer than 80 bits? – aspyct Mar 14 '17 at 8:22
• the input is used as a secret key now, to secure against brute force attack the secret key should be at least 80 bits long. – Tan Mar 15 '17 at 0:18
• What is that 80 bits based on? It makes 2^80 combinations, that I get, but how does that make it secure against bruteforce attacks. Why exactly 80, not 79 or 81? What about the future, as in related to the evolution of computational power? – aspyct Mar 15 '17 at 9:02
• There is nothing special about 80bit besides it is often cited as the minimum complexity which is currently not in reach for normal brute-forcing. The reason. This number is picked is that it is 160/2 which is the complexity to collide 160bit hashes like SHA-1 (which is regarded as barely strong enough for brute-force) – eckes May 11 '17 at 2:10