Jump to content

Pepper (cryptography): Difference between revisions

From Wikipedia, the free encyclopedia
Browse history interactively
← Previous edit
Content deleted Content added
VisualWikitext
Undid revision 885106389 by 173.64.109.100. Unfortunately, the new text was incorrect: even with a very strong hashing algorithm, weak passwords can be cracked. As for the original text, it's not magic. See the Adobe case: they encrypted their passwords and not a single password has been cracked through technical means (we can use the password hints to guess some of them, but the encryption and its key remain unbroken). A strong encryption key is needed of course. I clarified that in the article
m Switch "which" to "that" for people with the which-that distinction.
 
(46 intermediate revisions by 35 users not shown)
Line 1: Line 1:
{{short description|Cryptographic secret, more secure than a salt}}
{{Refimprove|date=November 2018}}
{{Lead rewrite|date=July 2024}}
In [[cryptography]], a '''pepper''' is a secret added to an input such as a [[password]] during [[hash function|hashing]] with a [[cryptographic hash function]]. This value differs from a [[Salt (cryptography)|salt]] in that it is not stored alongside a password hash, but rather the pepper is kept separate in some other medium, such as a Hardware Security Module.<ref>{{Cite web|url=https://pages.nist.gov/800-63-4/sp800-63b/authenticators/#memsecretver|title=NIST Special Publication 800-63B|date=2022-12-16|access-date=2023-10-10|at=Section 5.1.1.2|quote="...&nbsp;verifiers SHOULD perform an additional iteration of a keyed hashing or encryption operation using a secret key known only to the verifier"}}</ref> Note that the [[National Institute of Standards and Technology]] refers to this value as a '''secret key''' rather than a '''pepper'''. A pepper is similar in concept to a [[Salt (cryptography)|salt]] or an [[Key (cryptography)|encryption key]]. It is like a salt in that it is a randomized value that is added to a password hash, and it is similar to an encryption key in that it should be kept secret.


⚫
A pepper performs a comparable role to a [[Salt (cryptography)|salt]] or an [[Key (cryptography)|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.<ref name="Dropbox"/> A pepper should be long enough to remain secret from brute force attempts to discover it (NIST recommends at least 112 bits).
In [[cryptography]], a '''pepper''' is a secret added to an input such as a [[password]] prior to being [[hash function|hashed]] with a [[cryptographic hash function]]. As of 2017, NIST recommends<ref>{{Cite web|url=https://pages.nist.gov/800-63-3/sp800-63b.html#-5112-memorized-secret-verifiers|title=NIST Special Publication 800-63B|date=June 2017|access-date=2018-10-13|at=Section 5.1.1.2|quote="...&nbsp;verifiers SHOULD perform an additional iteration of a key derivation function using a salt value that is secret and known only to the verifier&nbsp;..."}}</ref> using a secret input when storing memorized secrets such as passwords.


== History ==
⚫
A pepper performs a comparable role to a [[Salt (cryptography)|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.
The idea of a site- or service-specific salt (in addition to a per-user salt) has a long history, with [[Steven M. Bellovin]] proposing a ''local parameter'' in a [[Bugtraq]] post in 1995.<ref>{{cite web|url=https://seclists.org/bugtraq/1995/Apr/143|title=passwd hashing algorithm|last=Bellovin |first=Steve |date=1995-04-16|website=seclists |access-date=2020-11-11}}</ref> In 1996 [[Udi Manber]] also described the advantages of such a scheme, terming it a ''secret salt''.<ref>{{cite journal|last1=Manber |first1=Udi|date=1996 |title=A simple scheme to make passwords based on one-way functions much harder to crack |url=https://dx.doi.org/10.1016%2F0167-4048%2896%2900003-x|journal=Computers & Security |volume=15 |issue=2 |pages=171–176 |doi=10.1016/0167-4048(96)00003-x |access-date=2020-11-11}}</ref> The term ''pepper'' has been used, by analogy to salt, but with a variety of meanings. For example, when discussing a [[Challenge–response authentication|challenge-response scheme]], pepper has been used for a salt-like quantity, though not used for password storage;<ref>{{cite journal|last1=Blake |first1=Ross|last2=Jackson|first2=Collin|last3=Miyake|first3=Nick| last4=Boneh|first4=Dan|last5=Mitchell|first5=John|date=2005|title=Stronger Password Authentication Using Browser Extensions |url=https://www.usenix.org/legacy/publications/library/proceedings/sec05/tech/full_papers/ross/ross_html/index.html |journal=USENIX Security Symposium |pages=17–32|access-date=2020-11-11}}</ref> it has been used for a data transmission technique where a pepper must be guessed;<ref>{{cite newsgroup | author = Lars Schoening| title = Hash only (Pepper) data transmission | date = January 25, 2006 | newsgroup = sci.crypt }}</ref> and even as a part of jokes.<ref>{{cite newsgroup | author = cyrusthevirus | title = Bruce Schneier Facts | date = June 7, 2007 | newsgroup = it.test | quote = Most people salt their hash. Bruce salt and peppers his. }}</ref>


The term ''pepper'' was proposed for a secret or local parameter stored separately from the password in a discussion of protecting passwords from [[rainbow table]] attacks.<ref>{{cite web|url=http://www.barkingiguana.com/2009/08/03/securing-passwords-with-salt-pepper-and-rainbows/ |title=Securing Passwords with Salt, Pepper and Rainbows |last=Webster |first=Craig |date=2009-08-03|website=Barking Iguana |access-date=2020-11-11}}</ref> This usage did not immediately catch on: for example, Fred Wenzel added support to [[Django (web framework)|Django]] password hashing for storage based on a combination of [[bcrypt]] and [[HMAC]] with separately stored [[Cryptographic_nonce|nonces]], without using the term.<ref name="django">{{cite web|url=https://github.com/fwenzel/django-sha2/commits/master/django_sha2/bcrypt_auth.py |title= History for django-sha2/django_sha2/bcrypt_auth.py |last=Wenzel |first=Fred |date=2011-03-12|website=Github |access-date=2020-11-11}}</ref> Usage has since become more common.<ref>{{cite mailing list | url=https://groups.google.com/d/msg/golang-nuts/qtK4oXWInJQ/REoNrvkNEDkJ |author=Patrick Mylund Nielsen|title=Generating Salt for encryption using golang | date=May 30, 2012 | mailing-list=golang-nuts}}</ref><ref name="vnhacker">{{cite web|url=https://vnhacker.blogspot.com/2020/09/why-you-want-to-encrypt-password-hashes.html|title=Why you want to encrypt password hashes |last=Duong |first=Thai |date=2020-09-05|website=vnhacker blogspot |access-date=2020-11-11}}</ref><ref>{{cite tweet |user= Sc00bzT|number= 1306780371258880007|date= 2020-09-18|title=Pepper use to mean "a non-cryptographic salt"}}</ref>
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. One downside of hashing passwords instead of encrypting passwords (assuming the encryption algorithm is strong and a strong key is used), is that an attacker can brute force the hashes and recover weak passwords. By contrast, with strong encryption, the attacker has to brute force a strong key (which may be physically impossible) before they can decrypt a single password. 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 if the pepper is breached, an attacker still has to brute force 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.


== Example usage ==
== Types ==
There are multiple different types of pepper:
{{See also|Salt (cryptography)#Example usage}}
* A secret unique to each user.{{citation needed|date=November 2020}}
Here is an incomplete example of using a constant pepper when storing passwords. This first table has two username and password combinations.
* A shared secret that is common to all users.<ref name="Dropbox">{{Cite web|last=Akhawe|first=Devdatta|title=How Dropbox securely stores your passwords|url=https://dropbox.tech/security/how-dropbox-securely-stores-your-passwords|access-date=2020-11-04|website=dropbox.tech|language=en}}</ref>
{| class="wikitable"
* A randomly-selected number that must be re-discovered on every password input.<ref>{{Cite web|url=https://www.usenix.org/legacy/events/sec99/full_papers/kedem/kedem.pdf|title=Brute Force Attack on UNIX Passwords with SIMD Computer|date=August 1999}}</ref>
|'''Username'''

|'''Password'''
== 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 by exhaustive search is intractable. 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.
|<tt>user1</tt>

|<tt>password123</tt>
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. Even with a list of (salt, hash) pairs, an attacker must also guess the secret pepper in order to find the password which produces the hash. The NIST specification for a secret salt suggests using a [[PBKDF2|Password-Based Key Derivation Function (PBKDF)]] with an approved [[Pseudorandom function family|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.
|-

|<tt>user2</tt>
== Unique pepper per user ==
|<tt>password123</tt>
In the case of a pepper that 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.
|}
The password is not stored, and the 8-byte (64-bit) pepper <tt>44534C70C6883DE2</tt> is stored in a secure location separate from the hashed values.
{| class="wikitable"
|'''Username'''
|'''String to be Hashed'''
|'''Hashed Value = SHA256 (Password + Pepper)'''
|-
|user1
|<tt>password123+44534C70C6883DE2</tt>
|<tt>D63E21DF3A2A6853C2DC675EDDD4259F3B78490A4988B49FF3DB7B2891B3B48D</tt>
|-
|user2
|<tt>password123+44534C70C6883DE2</tt>
|<tt>D63E21DF3A2A6853C2DC675EDDD4259F3B78490A4988B49FF3DB7B2891B3B48D</tt>
|}
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 attack|dictionary attacks]] and [[Brute-force attack|brute-force attacks]] so long as the attacker does not have the pepper value.


==See also==
==See also==
⚫
* [[passwd]]
* [[Salt (cryptography)]]
* [[Salt (cryptography)]]
* [[HMAC]]
⚫
* [[passwd]]


==References==
==References==
{{Reflist}}
{{Reflist}}

== External links ==
{{Cryptography navbox | hash}}


[[Category:Cryptography]]
[[Category:Cryptography]]

Latest revision as of 20:49, 6 November 2024

In cryptography, a pepper is a secret added to an input such as a password during hashing with a cryptographic hash function. This value differs from a salt in that it is not stored alongside a password hash, but rather the pepper is kept separate in some other medium, such as a Hardware Security Module.[1] Note that the National Institute of Standards and Technology refers to this value as a secret key rather than a pepper. A pepper is similar in concept to a salt or an encryption key. It is like a salt in that it is a randomized value that is added to a password hash, and it is similar to an encryption key in that it should be kept secret.

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.[2] A pepper should be long enough to remain secret from brute force attempts to discover it (NIST recommends at least 112 bits).

History

[edit]

The idea of a site- or service-specific salt (in addition to a per-user salt) has a long history, with Steven M. Bellovin proposing a local parameter in a Bugtraq post in 1995.[3] In 1996 Udi Manber also described the advantages of such a scheme, terming it a secret salt.[4] The term pepper has been used, by analogy to salt, but with a variety of meanings. For example, when discussing a challenge-response scheme, pepper has been used for a salt-like quantity, though not used for password storage;[5] it has been used for a data transmission technique where a pepper must be guessed;[6] and even as a part of jokes.[7]

The term pepper was proposed for a secret or local parameter stored separately from the password in a discussion of protecting passwords from rainbow table attacks.[8] This usage did not immediately catch on: for example, Fred Wenzel added support to Django password hashing for storage based on a combination of bcrypt and HMAC with separately stored nonces, without using the term.[9] Usage has since become more common.[10][11][12]

Types

[edit]

There are multiple different types of pepper:

  • A secret unique to each user.[citation needed]
  • A shared secret that is common to all users.[2]
  • A randomly-selected number that must be re-discovered on every password input.[13]

Shared-secret pepper

[edit]

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 by exhaustive search is intractable. 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. Even with a list of (salt, hash) pairs, an attacker must also guess the secret pepper in order to find the password which produces the hash. 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

[edit]

In the case of a pepper that 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.

See also

[edit]

References

[edit]
  1. ^ "NIST Special Publication 800-63B". 2022-12-16. Section 5.1.1.2. Retrieved 2023-10-10. ... verifiers SHOULD perform an additional iteration of a keyed hashing or encryption operation using a secret key known only to the verifier
  2. ^ a b Akhawe, Devdatta. "How Dropbox securely stores your passwords". dropbox.tech. Retrieved 2020-11-04.
  3. ^ Bellovin, Steve (1995-04-16). "passwd hashing algorithm". seclists. Retrieved 2020-11-11.
  4. ^ Manber, Udi (1996). "A simple scheme to make passwords based on one-way functions much harder to crack". Computers & Security. 15 (2): 171–176. doi:10.1016/0167-4048(96)00003-x. Retrieved 2020-11-11.
  5. ^ Blake, Ross; Jackson, Collin; Miyake, Nick; Boneh, Dan; Mitchell, John (2005). "Stronger Password Authentication Using Browser Extensions". USENIX Security Symposium: 17–32. Retrieved 2020-11-11.
  6. ^ Lars Schoening (January 25, 2006). "Hash only (Pepper) data transmission". Newsgroup: sci.crypt.
  7. ^ cyrusthevirus (June 7, 2007). "Bruce Schneier Facts". Newsgroup: it.test. Most people salt their hash. Bruce salt and peppers his.
  8. ^ Webster, Craig (2009-08-03). "Securing Passwords with Salt, Pepper and Rainbows". Barking Iguana. Retrieved 2020-11-11.
  9. ^ Wenzel, Fred (2011-03-12). "History for django-sha2/django_sha2/bcrypt_auth.py". Github. Retrieved 2020-11-11.
  10. ^ Patrick Mylund Nielsen (May 30, 2012). "Generating Salt for encryption using golang". golang-nuts (Mailing list).
  11. ^ Duong, Thai (2020-09-05). "Why you want to encrypt password hashes". vnhacker blogspot. Retrieved 2020-11-11.
  12. ^ @Sc00bzT (2020-09-18). "Pepper use to mean "a non-cryptographic salt"" (Tweet) – via Twitter.
  13. ^ "Brute Force Attack on UNIX Passwords with SIMD Computer" (PDF). August 1999.
[edit]
Retrieved from "https://en.wikipedia.org/enwiki/w/index.php?title=Pepper_(cryptography)&oldid=1255819875"