Pepper (cryptography)

In cryptography, a pepper is a secret added to an input such as a password prior to being hashed with a cryptographic hash function[1]. As of 2017, NIST recommends[2] using a secret input when storing memorized secrets such as passwords.

A pepper performs a comparable role to a salt, 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 (e.g. in a configuration file) 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, a pepper has to be secure to remain secret (at least 112 bits is recommended by NIST), otherwise an attacker only needs one known entry to crack the pepper. 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.

A pepper adds security to a database of salts and hashes because unless the attacker is able to obtain the pepper, they cannot crack a single hash, no matter how weak the original password[3]. One downside of hashing passwords instead of encrypting passwords, is that an attacker can brute force the hashes and recover weak passwords. The encryption equivalent of a pepper is the encryption key. By including pepper in the hash, one can have the advantages of both methods: uncrackable passwords so long as the pepper remains unknown to the attacker, and even in the case the pepper is breached, an attacker still has to crack the hashes. For comparison, when encrypting passwords, anyone with knowledge of the encryption key (including system administrators) can instantly decrypt all passwords; hence, it is always recommended to hash passwords instead of encrypting them, even when not using a pepper.[4]

Example usage

Here is an incomplete example of using a constant pepper when storing passwords. This first table has two username and password combinations.

Username Password
user1 password123
user2 password123

The password is not stored, and the 8-byte (64-bit) pepper 44534C70C6883DE2 is stored in a secure location separate from the hashed values.

Username String to be Hashed Hashed Value = SHA256(Password + Pepper)
user1 password123+44534C70C6883DE2 D63E21DF3A2A6853C2DC675EDDD4259F3B78490A4988B49FF3DB7B2891B3B48D
user2 password123+44534C70C6883DE2 D63E21DF3A2A6853C2DC675EDDD4259F3B78490A4988B49FF3DB7B2891B3B48D

In contrast to a salt, a pepper does not on its own protect against identifying users who have the same password, but it does protect against both dictionary attacks and brute-force attacks so long as the attacker does not have the pepper value.

See also

References

  1. Pornin, Thomas (March 2013). "How to securely hash passwords?". Information Security Stack Exchange. Retrieved 2018-10-13. ... The MAC key is your "pepper". Peppering makes sense if you can have a secret key which the attacker will not be able to read. ...
  2. "NIST Special Publication 800-63B". June 2017. Section 5.1.1.2. Retrieved 2018-10-13. ... verifiers SHOULD perform an additional iteration of a key derivation function using a salt value that is secret and known only to the verifier ...
  3. "Password hashing: add salt + pepper or is salt enough?". Information Security Stack Exchange. Retrieved 2018-10-13. ... Using the [pepper] does add to the strength of the password hash if compromise of the database does not imply compromise of the application. Without knowledge of the pepper the passwords remain completely secure. ...
  4. "Difference between Hashing a Password and Encrypting it". StackOverflow. Retrieved 2018-10-13. ... if you encrypt the passwords, your application has the key stored somewhere and an attacker who gets access to your database (and/or code) can get the original passwords by getting both the key and the encrypted text, whereas with a hash it's impossible. ...
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.