0

My app is a educational game for elementary schools, involving no money or anything of value, so I am not worried about sophisticated attackers having any interest in this. Still, I would like to follow best practices in case any of this code ever does wind up guarding something attractive.

The security consists of hashing values with a constant pepper to produce a hash. Generally, the values are things like the user id and other state info, and hash is used to preventing tampering (i.e., so you can't change the user id to a different value and access someone else's data).

Therefore, over time, the attacker has access to a large set of state info (the pre-hash) AND the hash, but not the pepper. The hash algorithm is also server-side and unknown (though limited in possibilities).

With this knowledge, can an attacker determine the pepper and hash algorithm and be able to generate a suitable hash for any message, breaking our security?

Joshua Frank
  • 207
  • 1
  • 6
  • 3
    Hashing algorithms are designed to be irreversible (https://crypto.stackexchange.com/questions/45377/why-cant-we-reverse-hashes). However if only a few bytes are unknown, it would be possible to able to guess the plaintext by brute force. If your pepper is large enough an attacker shouldn't be able to obtain it by inspecting the hash. – Neil Yoga Crypto Jun 21 '18 at 14:27
  • Since it's a constant pepper, knowing only the hash means you might know the state. And knowing that two users had the same hash at the same time means you know they are in the same state. Might not be very harmful, but that's still some information leakage. – Xenos Jun 21 '18 at 15:03
  • 1
    I'd add to Sword security's answer that 128 bits of entropy is considered "extremely good", and higher values aren't necessary, and don't provide any additional security. There's normally little reason to choose values of less than 128 bits. – Steve Sether Jun 21 '18 at 15:22

1 Answers1

2

This could be ok depending on the implementation, but it could also easily go wrong. An attacker would be unable to recover the pepper (assuming it has enough entropy), and they would be unable to hash arbitrary values.

However, your peppered hash is likely vulnerable to a length extension attack. If an attacker knows some data and its hash, this would allow them to append data while still being able to calculate the new hash as if they knew the pepper. To prevent this, instead of using the secret as a pepper, use it as the key for an HMAC. Even if you aren't worried about length extension attacks this is desirable, as it provides more security properties with no downsides, and it sounds like a MAC is what you're really after.

AndrolGenhald
  • 15,436
  • 5
  • 45
  • 50
  • Hmm, I had thought that hashing with a pepper *WAS* an HMAC, but reading more closely I see the difference. I should add the additional logic to harder it further. Thanks. – Joshua Frank Jun 21 '18 at 15:14