How is a pepper (a large constant number) used after a password has been salted with a salt by a hashing function such as bcrypt?

From Sybex CISSP Official Study Guide, 8th Edition (2018):

Adding a pepper to a salted password increases the security, making it more difficult to crack.

Is a pepper simply concatenated to the beginning or end of a salted password? Is it concatenated to the salted password, which is then hashed again?

  • A pepper only makes sense if you have a mean to make some short data more secure than the regular database. If the threat model is someone stealing the disk where all files reside, include the database, configuration, site secrets, certificates and keys, just don't bother with a pepper. You might instead encrypt the whole disk with a key protected by a TPM. – curiousguy Nov 13 '18 at 6:07
  • See also: How to apply a pepper correctly to bcrypt? – Jacco Nov 13 '18 at 11:31

Salt is a random string that is used to mitigate dictionary attacks.

|  id   |    salt    |       hashed_pw       |
| user1 | 9060d63fe0 | hash(pass19060d63fe0) |
| user2 | 39b3cdd660 | hash(pass239b3cdd660) |

Pepper is a fixed string that is more secret then the salt, and this mitigates brute force attacks on salted passwords.

Is a pepper simply concatenated to the beginning or end of a salted password? Is it concatenated to the salted password, which is then hashed again?

Peppers should not simply be concatenated because it's goal is to make brute forcing impossible. It too must be hashed.

Let's assume password abcd1234 and salt 9060d63fe0. If those two are hashed with bcrypt with round 9, the result will be $2a$09$T.FYSHNRG5W.EiS3ieAU/OqdnNLXtou3yZk98/ZJ0Y7JXAoFlVWKS.

If somehow hacker brute forces the password and manages to find the value abcd12349060d63fe0, the hacker will know that the salt value is 9060d63fe0 and the password is abcd1234 because salt is stored on the DB.

But let's assume a pepper is applied. pepper abab4321, password abcd1234 and salt 9060d63fe0. If hacker successfully brute forces and found abab4321abcd12349060d63fe0, the hacker won't be able to know which part is the pepper and which is the password.

Peppers can be applied before hashing like this:

|  id   |    salt    |          hashed_pw          |
| user1 | 9060d63fe0 | hash(pepperpass19060d63fe0) |
| user2 | 39b3cdd660 | hash(pepperpass239b3cdd660) |

Or after hashing like this

|  id   |    salt    |              hashed_pw               |
| user1 | 9060d63fe0 | hash(pepper + hash(pass19060d63fe0)) |
| user2 | 39b3cdd660 | hash(pepper + hash(pass239b3cdd660)) |
  • The problem with pepper is that a server penetration will provide the pepper. – zaph Nov 13 '18 at 7:38
  • @zaph Not will, it might. – Moonsik Park Nov 13 '18 at 7:46
  • One needs to assume the worst thus "will". "might" is just a chance, the attacker might not get the pepper. – zaph Nov 13 '18 at 7:47
  • @zaph the Idea is to store the pepper at another server and not in the DB. So if a attacker only gets access to the DB (e.g. by a SQL injection vulnerability) she is still missing the pepper. – Josef Nov 13 '18 at 8:56
  • 2
    @zaph Forensic security assumes the worst. Protective security do what’s best. Why do we even care about password hashing when WAS accepts passwords as plaintext? Hacker will modify WAS to get passwords plain text wouldn’t he? – Moonsik Park Nov 13 '18 at 9:23

It is not generally agreed upon how to use a pepper, whether it improves security, or what the term "pepper" even means.

  • Most sources indicate that the pepper should be integrated in the hash. However, Dropbox explicitly chose to use encryption rather than hashing, since this allows the pepper to be changed easily.
  • Most people suggest storing the pepper somewhere. However, it is also possible to hash a little bit of data along with the password and then throw that away, not storing it. This means that when the password needs to be verified the pepper needs to be brute-forced. This random data that is not stored is sometimes also referred to as pepper, which creates confusion with the stored kind.
  • Some people argue that if your hashes are compromised, your whole application is compromised thus the pepper is also compromised if you store it within your application. This would mean that the pepper does not offer any real security.
  • Hashing functions for passwords often have support for salts but not for peppers. This means that you have to invent some way to put the pepper in yourself. This is generally a bad idea with cryptography and can lead to serious problems.

Concluding, I don't think there is consensus about whether applications should use a pepper or not. Most applications I have seen do not incorporate a pepper in their password hashing algorithm.


There is a better way, to add a server side key to the password hashing procedure. Instead of adding it to the password before hashing, you can encrypt the already calculated password hash.

  1. The key can be exchanged whenever this is necessary (decrypt all password-hashes and reencrypt them with the new key).
  2. You get the same advantages as with a pepper, the attacker needs additional privileges on the server to get the key/pepper, the hashes alone won't do.

Keep in mind, that a pepper protects passwords only as long as the key/pepper stays secret, a typical scenario is SQL-injection.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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