3

Saying we have an oracle that an attacker can use as many time as they want. The attacker can send a non-empty password to this Oracle. The Oracle hashes the password using sha256(password + pepper), and sends this to the attacker.

The pepper value never changes (it's a bad constant salt).

Is there a way an attacker can guess the pepper? How would the attacker call the Oracle to get that pepper?

Do the same attack applies if the Oracle uses a hash_hmac('sha256', password, pepper) method instead of simple sha256(password + pepper)? Do this applies for sha256(pepper + password) instead of sha256(password + pepper)?

I've seen the question Is it possible to get the salt if I have the hash and original password? but there, we have one more condition: attacker can get as many hash; original password couple as they want to recover the constant pepper, so this condition might change a lot?

My guess is that one can do retrieve the pepper, but I'm not sure how it would be done. The process to retrieve it is not that much important, but I want to get a proof that such process exists and is do-able.

Xenos
  • 1,331
  • 8
  • 16
  • 1
    Send in a blank password and then brute-force it. Try with an online rainbow table first: might be quicker – Stephane Jun 14 '18 at 13:46
  • 1
    Since you edited your question to disallow empty password, use a simple, one-letter password (like "a" or "0") and then brute-force the resulting hash – Stephane Jun 14 '18 at 13:49
  • @Stephane Neat, indeed, but I'll add a "non-empty password" condition then. And we can consider that pepper is a "hudge random" list of 128 alphanumeric character, so rainbow tables have almost no chance to work. |Edit You would then get the sha256 of `aJZAF54FR7e65afazeZAD`, but I don't see how you can find the pepper `JZAF54FR7e65afazeZAD` from there? – Xenos Jun 14 '18 at 13:50
  • I've kept digging and it seems really close to that from CryptoExchange: https://crypto.stackexchange.com/questions/8087/sha256-hmac-brute-force-with-chosen-plaintext-attacks#8089 So answer is: No, there's no practical way (yet) – Xenos Jun 14 '18 at 14:14

3 Answers3

1

An attacker that knows the password and the hash but not the pepper is in the same position as the attacker that knows the salt and hash, but not the password.

Putting in another way: hashedValue = hashFunction('thing attacker have', 'thing attacker does not have').

On the classic leaked database attack, the attacker knows the salt and the hash, not the password. On your case, he knows the password and the hash. Looks different, but it's exact the same. Nothing different at all.

Difficulty? It depends on the length of the pepper. If it's a 128 byte random string, is as difficult as bruteforcing a 128 byte random password.

ThoriumBR
  • 50,648
  • 13
  • 127
  • 142
  • IMO, it actually largely differs because the leaked DB has *ALL same passwords* (the pepper here is *constant*). So, reworded: on a leaked DB where all passwords are the same and I know the salt (I can even forge it to an arbitrary value), how do I recover the password? – Xenos Jun 14 '18 at 15:34
  • 1
    I think you meant 128 bits, not 128 bytes (1 byte=8 bits) or 1024 bits. Brute forcing a random 128-**bit** password (2^128) at a rate of billion guesses per second per computer requires a 10 billion computers running for 10 billion years to have a 1% chance of finding it (and this assuming you coordinate the 10 billion computers properly for 10 billion years to never check same one twice). Brute forcing 1024 bit password is 10^269.7 times harder than a 128-bit password. That said, a 1024 bit password doesn't help unless you have a 1024-bit or bigger hash function (most are 128/256/512 bit). – dr jimbob Jun 14 '18 at 16:17
  • OP commented that _pepper is a "hudge random" list of 128 alphanumeric character_, so is really a 128-byte string. – ThoriumBR Jun 14 '18 at 17:55
  • That's in fact 128 alphanumeric characters, so it's around a 762 bits key if you prefer. Still, we can consider it "long enough" for avoiding direct brute force attack. – Xenos Jun 15 '18 at 07:50
0

The easiest way is through brute force which depends on the size of the pepper. Otherwise it would take a cryptographic attack against SHA-256 itself. No such attacks are currently known.

Is there a way an attacker can guess the pepper? How would the attacker call the Oracle to get that pepper?

If the unknown input is sufficiently small, regular exhaustive search may be able to find it. Otherwise, it would take a severe cryptographic vulnerability in SHA-256 itself.

Do the same attack applies if the Oracle uses a hash_hmac('sha256', password, pepper) method instead of simple sha256(password + pepper)?

An HMAC mitigates length extension attacks, which are of no use to the attacker here. There are some attacks which an HMAC can make harder, such as collision attacks (MD5 is vulnerable to collisions with 218 difficulty, but HMAC-MD5 is not with around the expected 264 difficulty, for example). These attacks are not relevant here either. In theory, HMAC may make some attacks harder, but assuming SHA-256 is an ideal PRF, an HMAC provides no benefit.

Do this applies for sha256(pepper + password) instead of sha256(password + pepper)?

The former is more secure in theory. This is because you could calculate what H(a || b) would be, even if you are given only H(a) by exploiting a length extension attack. As such, H(a || b) is provably no less secure than H(a). When done the other way around, this may be less secure (in theory). This is because H(b || a) is equivalent to H'(a), where H' is SHA-256 with H(b) as the IV. A preimage that allows the attacker-controlled b to resolve to a weak IV may make H'(a) weaker.

forest
  • 64,616
  • 20
  • 206
  • 257
-1

There's three potential ways the attacker can determine the pepper.

  1. Implementation bugs in the Oracle. If the Oracle has a bug, such that it leaks information about the pepper (buffer overflow, etc), the attacker might be able to determine the pepper.

  2. Low entropy pepper. If the pepper has very low entropy of say 32 bits, it's trivial to give the Oracle a known password, then on your own computer simply do sha256(known_password+n), for all 32 bits of n until you get back the value the Oracle gave you. If the pepper is sufficiently large this is infeasible.

  3. A newly found design flaw in SHA256 that leaks information about what's hashed. (There are no known design flaws like this as of June 2018).

Steve Sether
  • 21,480
  • 8
  • 50
  • 76
  • An oracle by definition has no bugs. – forest Jun 15 '18 at 03:18
  • @forest Maybe so, but that's a pretty silly way to think of the world. – Steve Sether Jun 15 '18 at 04:05
  • Cryptography is a silly subject I suppose. Absolutes are very important to such things. It's intended to prevent unnecessary loopholes like "a bug in the oracle". Saying something is an oracle is essentially saying "assume this function does so-and-so, and understand that anything not explicitly presented here is out of scope". Otherwise, for example, no one could say XTS is provably secure without saying "if the underlying block cipher is an ideal PRP". Obviously it might not be an ideal PRP, but no one wants to read "but AES might be flawed" in a paper about the security of XTS. – forest Jun 15 '18 at 04:40
  • @forest That's fine, and in the scope of a mathematics paper I can see that (though frankly any decent paper should talk about difficulty of implementation). I see this forum as more real world, and shouldn't include things like mathematical abstractions like perfect implementations. You can always just hit the right guy with a $5 wrench to break the "unbreakable encryption" for instance. – Steve Sether Jun 15 '18 at 14:06