Pepper (cryptography)

In cryptography, a pepper is a secret added to an input such as a password during hashing with a cryptographic hash function.

There are multiple different types of pepper:

• A secret salt unique to each user that is not stored along with the password hash, but rather in some other medium, such as a Hardware Security Module. Note that NIST never refers to this value as a pepper but rather as a secret salt
• A shared secret salt or encryption key that is common to all users
• A randomly-selected number that must be re-discovered on every password input

A pepper performs a comparable role to a salt or an encryption key, but while a salt is not secret (merely unique) and can be stored alongside the hashed output, a pepper is secret and must not be stored with the output. The hash and salt are usually stored in a database, but a pepper must be stored separately to prevent it from being obtained by the attacker in case of a database breach. Where the salt only has to be long enough to be unique per user, a pepper should be long enough to remain secret from brute force attempts to discover it (NIST recommends at least 112 bits).

Shared Secret Pepper

In the case of a shared-secret pepper, a single compromised password (via password reuse or other attack) along with a user's salt can lead to an attack to discover the pepper, rendering it ineffective. If an attacker knows a plaintext password and a user's salt, as well as the algorithm used to hash the password, then discovering the pepper can be a matter of brute forcing the values of the pepper. This is why NIST recommends the secret value be at least 112 bits, so that discovering it is intractable. Finally, the pepper must be generated anew for every application it is deployed in, otherwise a breach of one application would result in lowered security of another application. Without knowledge of the pepper, other passwords in the database will be far more difficult to extract from their hashed values, as the attacker would need to guess the password as well as the pepper.

A pepper adds security to a database of salts and hashes because unless the attacker is able to obtain the pepper, cracking even a single hash is intractable, no matter how weak the original password. The NIST specification for a secret salt suggests using a Password-Based Key Derivation Function (PBKDF) with an approved Pseudorandom Function such as HMAC with SHA-3 as the hash function of the HMAC. The NIST recommendation is also to perform at least 1000 iterations of the PBKDF, and a further minimum 1000 iterations using the secret salt in place of the non-secret salt.

Unique Pepper Per User

In the case of a pepper which is unique to each user, the tradeoff is gaining extra security at the cost of storing more information securely. Compromising one password hash and revealing its secret pepper will have no effect on other password hashes and their secret pepper, so each pepper must be individually discovered, which greatly increases the time taken to attack the password hashes.

Randomly Selected Pepper

In the case of a randomly-selected pepper which is not saved at all, it must be rediscovered every time it is needed. This means that an algorithm to verify a password would effectively need to brute-force the pepper every time. For this reason, algorithms implementing this would not want to use a large value for the pepper, as verification should be reasonably fast.

See also

• Salt (cryptography)
• HMAC
• passwd