How is a pepper used with salted passwords?

Question

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?

Answer 1

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)) |
+-------+------------+--------------------------------------+

Answer 2

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.

Answer 3

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.