44

Update: There is a better way to add a server side key, than using it as a pepper. With a pepper an attacker must gain additional privileges on the server to get the key. The same advantage we get by calculating the hash first, and afterwards encrypting the hash with the server side key (two way encryption). This gives us the option to exchange the key whenever this is necessary.

For hashing passwords in a database, i would like to add a pepper to the hash function. Of course this pepper will be additionally to the unique salt.

The reason why i want to add a pepper is, that it prevents a dictionary attack, in case that the attacker has only access to the database, but not to the server (typical for Sql-Injection). In my opinion this is better than a hash without pepper, even if the pepper is only hardcoded (to avoid code complexity).

Now i wonder, how the pepper should be applied correctly, is it correct to just append the pepper to the password before hashing?

1. Concatenating password and pepper

$passwordHash = bcrypt($password . $pepper, $salt);

A reason against this could be, that passwords bigger than the bcrypt limit (55 characters) will not get the pepper, although passwords of this length are propably not in a dictionary anyway. Because of this limit, the pepper is added after the password and not before. Another reason could be, that if the attacker knows the pepper, he also knows the ending of all our peppered passwords.

2. Combine password and pepper with hash

$passwordHash = bcrypt(hash('sha256', $password . $pepper), $salt);

So we could use a hash function to combine password and pepper, before hashing. Is it appropriate to use sha256, or which hash function would be ideal, when we want to use bcrypt afterwards?

3. Combine password and pepper with hmac

$passwordHash = bcrypt(hash_hmac('sha256', $password, $pepper), $salt);

Often a hmac is the recommended solution, is there any advantage over using SHA256 directly? Since we only want to combine password and pepper, and the security comes later from the bcrypt, i cannot see any apparent advantage.

Any helpful hints are much appreciated.

Improve this question
13
  • Isn't hash_hmac('sha256', $pepper, $password) will be more correct (use $pepper as HMAC's key)?
    – Powerman
    Apr 24, 2014 at 19:31
  • Is there any difference for security between bcrypt(hmac($pepper, $password), $salt) and hmac($pepper, bcrypt($password, $salt))?
    – Powerman
    Apr 24, 2014 at 19:32
  • @Powerman - There is a better way to add a server side key to the hash, i updated my answer to point it out. Doing it this way you cannot decrease security, because in the worst case an attacker just gets the original hashes. I wrote a tutorial about safely storing passwords, where i tried to describe it more indepth.
    – martinstoeckli
    Apr 25, 2014 at 6:28
  • Nice tutorial, but why do you think encrypt() is any way better than hmac()? At a glance it's much worse: 1) it's (needlessly, after bcrypt) slower; 2) when attacker know pepper he can just decrypt() to get bcrypt's result and then bruteforce using just bcrypt, while with HMAC he will need to do bruteforce using hmac+bcrypt which complicate things a little for him; 3) with wrong encryption algo or mode (CBC/EBC) it may be possible to analyse encrypted hashes from db to reveal encryption key (pepper).
    – Powerman
    Apr 25, 2014 at 13:19
  • @Powerman - The purpose of the key is, that the attacker needs to gain additional privileges on the server (he needs the key, the database alone won't do), not to make the hash more safe (this is the job of BCrypt). Of course if the encryption is done wrong you may get the hashes, that's what Thomas mentioned, but this is a question of using a good library. The advantage is, that you can exchange the key whenever you have need to, even periodically. Another discussed point is, that you do not interfere in any way with the hash algorithm.
    – martinstoeckli
    Apr 25, 2014 at 15:12

1 Answer 1

Reset to default
35

Your three methods are correct. The third (with HMAC) might be a tad more "elegant", mathematically speaking: it would make it easier to prove the security of the construction, relatively to those of bcrypt and HMAC.

Beware, though, of null bytes. A given bcrypt implementation might expect a character string and stop at the first byte of value 0, which may occur in the output of either SHA-256 or HMAC (or as part of the binary key you use as pepper), ignoring all subsequent bytes. It would be a grave problem, and you would not notice it. To avoid that problem, you might want to Base64-encode the SHA-256 or HMAC output before giving it to bcrypt (Base64-encoded SHA-256 output is 44 characters, still below the bcrypt limit).

Improve this answer
8
  • 1
    Thanks a lot for this helpful answer, especially the tip about binary output. So you see no obvious problems with just concatenating password and pepper?
    – martinstoeckli
    Oct 7, 2012 at 21:10
  • 1
    As long as the pepper is of fixed size (so that it could be unambiguously "removed"), and you do not exceed the 55-character limit, and avoid the troublesome zeros, then concatenation should be fine.
    – Thomas Pornin
    Oct 7, 2012 at 21:13
  • Given that BCrypt doesn't actually have a "pepper" input, isn't it potentially safer to either encrypt or HMAC the password digest? Peppers feel very much to me like inventing your own crypto.
    – Stephen Touset
    Oct 7, 2012 at 21:14
  • 3
    bcrypt is meant to tolerate passwords as input. Passwords are about the worst kind of input you can get; I do not see harm coming that way, when adding a MAC. The danger here would be that the addition of the "pepper" induces two distinct passwords to yield the same bcrypt input, e.g. because of an unwanted truncation from a null byte. Apart from that, anything which looks like an injection can be applied to the input of bcrypt as a preparation step (hashing or MACing is injective-like because finding collisions is hard).
    – Thomas Pornin
    Oct 7, 2012 at 21:20
  • What about applying an HMAC or encrypting the output? Although with standard BCrypt libraries, an HMAC might be annoying since they don't typically provide explicit access to the salt and cost factor in the input or output.
    – Stephen Touset
    Oct 7, 2012 at 21:28

You must log in to answer this question.

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