Hubbry Logo
Pepper (cryptography)Pepper (cryptography)Main
Open search
Pepper (cryptography)
Community hub
Pepper (cryptography)
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Pepper (cryptography)
Pepper (cryptography)
Pepper (cryptography)
View on Wikipedia
from Wikipedia

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]

Algorithm

[edit]

An incomplete example of using a pepper constant to save passwords is given below.

Username Password
user1 password123
user2 password123

This table contains two combinations of username and password. The password is not saved, and the 8-byte (64-bit) 44534C70C6883DE2 pepper is saved in a safe place separate from the output values of the hash.

Username Hashing string Hash output value = SHA256 (Password + pepper)
user1 password123+44534C70C6883DE2 D63E21DF3A2A6853C2DC675EDDD4259F3B78490A4988B49FF3DB7B2891B3B48D
user2 password123+44534C70C6883DE2 D63E21DF3A2A6853C2DC675EDDD4259F3B78490A4988B49FF3DB7B2891B3B48D

Unlike the salt, the pepper does not provide protection to users who use the same password, but protects against dictionary attacks, unless the attacker has the pepper value available. Since the same pepper is not shared between different applications, an attacker is unable to reuse the hashes of one compromised database to another. A complete scheme for saving passwords usually includes both salt and pepper use.

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 prohibitively expensive. 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]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Pepper (cryptography)

View on Grokipedia
from Grokipedia
In , a pepper is a secret, application-wide value added to user passwords or other inputs prior to hashing with a , serving as an additional layer of protection against offline attacks on stolen password databases. Unlike a salt, which is a unique, publicly stored random value per password to prevent precomputed attacks, a pepper is shared across all users, kept confidential, and stored separately from the database—typically in a (HSM) or secure system—to ensure it remains unknown even if the database is compromised. This dual approach of salt and pepper combines per-user uniqueness with system-wide secrecy, making it significantly harder for attackers to crack multiple passwords from a breached without access to the pepper. Peppers can be applied in two primary ways: pre-hashing, where the pepper is concatenated or combined with the password and salt before the initial hash computation (e.g., via PBKDF2, bcrypt, or Argon2), or post-hashing, where the result of the salted password hash is further processed using the pepper as a key in an HMAC operation (e.g., HMAC-SHA256(password_hash, pepper)). For optimal security, peppers should be generated as cryptographically secure random values with at least 32 bytes of entropy to resist brute-force attempts, and they must never be stored alongside hashed passwords to maintain their secrecy. If a pepper is compromised, it necessitates a full password reset for all users, though rotation schemes—such as maintaining multiple peppers and gradually migrating hashes—can mitigate this risk without immediate disruption. The concept of a pepper originated in the mid-1990s as an enhancement to authentication schemes, with early proposals including Udi Manber's 1996 description of a "secret salt" to exponentially increase cracking difficulty through repeated hashing iterations, and a 1997 technical note by Martín Abadi, T. Mark A. Lomas, and Roger Needham on strengthening user-chosen via server-side secrets without burdening users. Although not universally adopted initially due to implementation complexity, peppers gained prominence in modern security guidelines from organizations like and IETF, particularly for defending against advanced threats such as GPU-accelerated dictionary attacks and password shucking techniques. Today, they are recommended as a in layered storage, complementing adaptive hashing functions to balance usability and robust protection.

Fundamentals

Definition

In cryptography, a pepper is a secret value that is appended or otherwise combined with an input, typically a , prior to applying a , thereby distinguishing it from non-secret elements such as salts. This secret is designed to enhance the security of the hashing process by introducing an additional layer of protection that is not derivable from the stored data alone. The primary purpose of a pepper is to require an attacker to possess both the hashed output and knowledge of the pepper itself in order to verify or attempt to crack the original input, thereby mitigating risks from database breaches where only the hashes are compromised. According to NIST guidelines, this aligns with the concept of a "secret key" used in verifiers, where verifiers perform an additional keyed hashing or operation known only to the verifier to bolster resistance against offline attacks. Key characteristics of a pepper include its strict confidentiality, which must be maintained separately from the hashed values, and its potential application either application-wide or per-user without storage alongside the hashes. Unlike salts, which are publicly stored and unique per hash, peppers remain hidden to prevent straightforward reversal or rainbow table attacks. A basic example involves concatenating the pepper to the password before hashing, such as computing hash(password∥pepper)\text{hash}(\text{password} \Vert \text{pepper}), where ∥\Vert denotes concatenation.

Comparison to Salt

In password hashing, a salt is a unique, randomly generated value appended to each user's password prior to hashing, which is stored alongside the resulting hash in the database to prevent precomputed attacks such as rainbow tables on identical passwords across multiple users. While both salt and pepper serve to enhance the security of password hashes by adding additional inputs, they differ fundamentally in secrecy and application: a salt is non-secret, unique per user or hash instance, and publicly stored with the hash to ensure uniqueness and thwart bulk precomputation attacks, whereas a pepper is a secret value, often shared across users, stored separately from the database (such as in secure hardware or configuration files) to protect against database-only breaches. Peppers and salts are complementary and frequently employed together in robust password storage schemes, where the salt provides per-instance uniqueness to counter rainbow table and identical-password attacks, and the pepper adds a layer of global secrecy that requires an attacker to compromise additional system components beyond the database to perform offline brute-force attempts. Without a pepper, a compromised database exposes salted hashes directly to brute-force or attacks, as the salts are already available; conversely, a salt alone offers no if the entire —including pepper storage—is breached, allowing an attacker to reconstruct the full hashing inputs.

History

Origins

The concept of a pepper in cryptography originated in the mid-1990s as a means to bolster security in distributed systems against offline attacks. In April 1995, Steven M. Bellovin proposed the use of a "local "—a system-specific string prepended or appended to the before hashing—to enhance protection without relying solely on the standard UNIX crypt() function, which was becoming vulnerable due to hardware advancements allowing faster cracking. This approach aimed to introduce an additional layer of secrecy tied to the local environment, making it difficult for attackers who obtained the hashed passwords to perform or brute-force attacks without access to the . Bellovin's suggestion emerged amid growing concerns over the limitations of early hashing, such as the 8-character limit and low in user-chosen passwords, which exposed systems to efficient offline exploitation. Building on this idea, further developed the concept in 1996 by introducing a "secret salt" in the context of one-way hash functions for . In his paper, Manber described a scheme where a secret value, not stored alongside the salted password hashes in the database, is incorporated into the hashing process to multiply the computational effort required for cracking by 100 to 1000 times. This secret salt functioned similarly to Bellovin's local parameter but emphasized its role in preventing precomputed attacks and offline guessing, as the attacker would need both the database and the secret to verify guesses efficiently. Manber's proposal was published in Computers & Security, highlighting its practicality for implementation in systems. In 1997, Martín Abadi, T. Mark A. Lomas, and Roger Needham extended these ideas in a technical note on strengthening user-chosen passwords. They proposed using a server-side secret combined with the password during hashing, stored separately to protect against database compromises without requiring users to manage additional secrets. This approach further emphasized the benefits of confidential additives in enhancing security against offline attacks. These early ideas were motivated by the vulnerabilities inherent in contemporary systems, such as the DES-based crypt() algorithm, which, despite incorporating a public salt, allowed rapid offline attacks once hashes were stolen—predating the adoption of more robust functions like in 1999. The proposals addressed the rising need for secure as the expanded in the mid-1990s, where distributed networks increasingly relied on shared files susceptible to compromise. By requiring knowledge of a non-stored secret, peppers aimed to force attackers into online verification or repeated full computations, significantly raising the bar for breaches.

Terminology and Evolution

The concept of adding a secret value to password hashing, akin to a pepper, traces back to the under the term "secret salt." In a technical report, described a scheme employing both a public salt (stored with the hash) and a secret salt (discarded after use during verification), which multiplies the effort required for offline guessing attacks by the number of possible secret salt values, typically 100 to 1,000. This approach built on earlier salting mechanisms in systems like UNIX, aiming to deter and brute-force attacks without altering core routines. The specific term "pepper" emerged in 1999 through the work of Gideon Kedem and Yoshio Ishihara, who introduced "pepper bits" in their analysis of brute-force attacks on UNIX passwords using SIMD computers. Unlike stored salts, these pepper bits were random values incorporated into the password encryption process but never saved, thereby requiring attackers to account for an unknown factor even after obtaining the database. Although the 1999 definition provided a clear distinction from salts, the term did not immediately gain widespread adoption in cryptographic literature. By the late 2000s and early 2010s, "pepper" began appearing more frequently in forums and papers as a descriptor for a fixed, secret additive—often application-wide—to differentiate it from per-user salts and emphasize its role in thwarting offline cracking. A key milestone was its formal inclusion in the Password Storage Cheat Sheet around 2013, which positioned peppering as a recommended practice to add a layer of beyond salting, particularly when the secret is stored outside the database (e.g., in hardware or environment variables). This guidance highlighted peppers' utility in limiting the immediate exploitability of stolen hashes. The concept achieved broader standardization in 2017 with NIST Special Publication 800-63B, which defined a "secret salt value" (synonymous with pepper) as an additional input for hashing memorized secrets, mandating its separate storage from the verifier database to enhance during . Updated with errata in December 2017 and further revised (with Revision 4 finalized in July 2025), the guideline underscored peppers' role in systems, integrating them into federal frameworks. In the 2020s, peppers have seen increased emphasis in industry reports and guidelines for bolstering post-breach resilience, especially in and multi-tenant architectures where shared demands robust, layered defenses against compromised . For instance, OWASP's ongoing updates and NIST's revisions stress peppers' value in such environments to ensure that even breached salts do not enable straightforward recovery.

Types

Shared-Secret Pepper

A shared-secret pepper, also known as an application-wide pepper, is a single confidential value applied uniformly to the hashing process for all users in a . Unlike per-user salts, this pepper is not stored alongside the hashed in the database but is instead maintained in a central, secure location to add an extra layer of protection against unauthorized access to the store. The shared-secret pepper is typically combined with the user's password and a unique salt prior to applying the hashing algorithm, ensuring that even if the database is compromised, the attacker lacks the necessary secret to verify or crack the hashes efficiently. A common implementation concatenates these elements as input to the hash function, such as H(salt∥password∥pepper)\text{H}( \text{salt} \parallel \text{password} \parallel \text{pepper} ), where ∥\parallel denotes and H\text{H} is a secure hashing like or ; alternatively, the pepper can serve as a key in a post-hash operation for enhanced security, e.g., HMAC-H(H(salt∥password),pepper)\text{HMAC-H}( \text{H}( \text{salt} \parallel \text{password} ), \text{pepper} ). This approach offers advantages in simpler management for smaller-scale systems, as only one secret needs to be generated, stored, and rotated, providing a consistent protection baseline across all accounts without the overhead of individual secrets. It also bolsters defense in depth by rendering database-only compromises ineffective for offline attacks, as the pepper's secrecy prevents the use of precomputed rainbow tables or straightforward brute-forcing. However, the shared-secret pepper introduces a critical drawback as a : if it is compromised—through server access, misconfiguration, or insider threats—all hashes become vulnerable to brute-force attacks, potentially requiring a full-scale reset for every user affected. Secure storage is essential to mitigate this, often using mechanisms like hardware security modules (HSMs) or environment variables in protected configurations, though the latter must be handled carefully to avoid exposure.

Unique Pepper per User

Although the standard definition of a pepper is an application-wide secret, a less common variant proposed in some academic literature involves a unique pepper per user, referring to a distinct cryptographic secret generated and assigned exclusively to each user account in a password authentication system. This approach is not part of mainstream security guidelines such as those from or IETF. This secret is combined with the user's password and a unique salt during the hashing process, such as by computing the hash function on the concatenated input salt || password || user_pepper, resulting in a stored hash value alongside the salt and user identifier. The design ensures that each user's password hash incorporates a personalized secret component, enhancing protection beyond standard salting. The user pepper is stored separately from the password database to maintain its secrecy, often in an encrypted key vault or hardware security module that allows secure retrieval tied to the user identifier. During authentication, the system fetches the salt from the database and the pepper from this secure store, then hashes the provided password using the same combination for comparison against the stored value. This separation prevents offline attacks on the hashes without additional compromise of the pepper storage. In contrast to shared-secret peppers used application-wide, the per-user variant applies the secret only to individual verifications. User peppers are generated as cryptographically secure random values, with a recommended minimum length of 32 bytes to resist brute-force attacks effectively. Periodic rotation of these peppers is advised, typically aligned with overall policies, to address potential long-term exposures without requiring immediate rehashing of all passwords. This per-user approach limits the impact of breaches by isolating accounts; a compromised pepper affects only the associated user, preventing widespread exposure that could occur with a . It also facilitates scalability for large user bases, as the distributed nature avoids a while maintaining computational efficiency during verification.

Implementation

Algorithmic Use

Peppers are integrated into password hashing algorithms through various computational methods that incorporate the secret value to enhance the input to the hash function. One common approach is concatenation, where the pepper is appended to the password before hashing, as in SHA-256(password∣∣pepper)\text{SHA-256}(\text{password} || \text{pepper}), with ∣∣|| denoting concatenation. Alternatively, the pepper can be XORed with the password or used as the key in an HMAC construction prior to the primary hashing step, such as HMAC-SHA-256(=password,pepper)\text{HMAC-SHA-256}(\text=password, \text{pepper}) followed by further derivation. In key derivation functions like PBKDF2, the pepper serves to preprocess the password, for example, PBKDF2(HMAC-SHA-256(password, pepper), salt, iterations=310000, PRF=HMAC-SHA-256). Specific algorithms demonstrate practical integration of peppers. For , a pre-hashing step applies the pepper via before the main operation, such as bcrypt(base64(HMAC-SHA-384(password,pepper)),salt,cost)\text{bcrypt}(\text{base64}(\text{HMAC-SHA-384}(\text{password}, \text{pepper})), \text{salt}, \text{cost}), where the cost parameter controls computational intensity. Peppers are also compatible with advanced memory-hard functions: Argon2id accepts the pepper directly as an optional secret key parameter in its computation, as defined in RFC 9106, allowing secure incorporation without altering the core algorithm. For , integration typically involves a preliminary with the pepper to preprocess the password, followed by scrypt(password', salt, N, r, p), ensuring resistance to hardware-accelerated attacks. NIST SP 800-63B recommends the use of an additional secret salt (pepper), stored separately, with approved key derivation functions like using or families (per FIPS 202), incorporated as an input to the function. The verification process during authentication relies on precise recomputation using the pepper. Upon receiving a login attempt, the system retrieves the pepper and the user's salt from secure locations, then applies the same hashing algorithm—incorporating the pepper as configured—to the submitted password, producing a candidate hash. This is compared to the stored hash using a constant-time equality check to mitigate timing-based side-channel attacks. If the hashes match, authentication succeeds; otherwise, it fails, ensuring the pepper's secrecy prevents offline attacks on stolen hashes.

Storage Methods

Peppers must be stored in a manner that ensures their secrecy, separate from the database containing user passwords, salts, and hashes to mitigate risks from data breaches. Common secure storage methods include Hardware Security Modules (HSMs), which offer tamper-resistant environments for protecting cryptographic secrets through physical and logical safeguards. Encrypted configuration files, secured with strong access controls and encryption, provide another option for on-premises deployments. Cloud-based key management services, such as AWS Key Management Service (KMS), enable centralized storage with automated encryption, audit logging, and policy-based access. Under no circumstances should peppers be stored in the user database, as this would expose them alongside compromised credentials. For shared-secret peppers, applicable across all users, storage occurs on centralized servers with strict access controls to limit retrieval to authorized processes only. These systems incorporate rotation policies, where peppers are periodically regenerated and passwords rehashed with the new value to maintain security over time. Unique peppers per user require individualized protection, typically involving of each pepper in separate secure vaults. Envelope is employed here, where the per-user pepper serves as a key encrypted by a master key held in an HSM or cloud service, allowing efficient decryption during without exposing the pepper at rest. To achieve optimal security, peppers may be derived from a master key using a (KDF), such as , which minimizes the storage of multiple independent secrets while enabling rotation of the master key. Access to stored peppers should include comprehensive of retrieval attempts and tamper detection mechanisms to identify and respond to potential unauthorized access. This storage approach integrates with the algorithmic combination of pepper, salt, and during hashing.

Security Aspects

Benefits

Peppers enhance the security of password hashing by providing an additional secret value that is not stored alongside the hashed passwords and salts in the database. If an attacker compromises the database through a breach, such as via , they obtain only the salted hashes without the pepper, rendering offline cracking attempts significantly more difficult as the attacker must also guess or obtain the pepper to validate any candidate passwords. When combined with per-user salts, peppers further thwart and attacks by ensuring that precomputed tables cannot be directly applied to the hashes; the absence of the pepper forces the attacker to perform computationally expensive operations akin to online verification for each guess, even in an offline scenario. Peppers also support secure key derivation in setups, adding a layer of protection for verifying memorized secrets. According to NIST guidelines (SP 800-63B, rev. 4, 2025), incorporating a secret input like a pepper in the hashing process helps resist offline attacks on authenticators. Quantitatively, a pepper with sufficient —such as 112 bits—increases the effective search space of the hashed by approximately that amount, exponentially raising the computational cost for brute-force attacks.

Risks and Mitigations

One primary risk associated with shared-secret peppers is that a of the central storage exposes all users' hashes to offline attacks, as the same pepper applies universally and enables attackers to recompute hashes once obtained. errors, such as loss of the pepper value, can lead to denial-of-service conditions, preventing legitimate password verification until all affected users reset their credentials. Additionally, if the pepper is insufficiently strong—such as lacking adequate (e.g., fewer than 112 bits of strength, per NIST SP 800-63B)—it becomes susceptible to brute-force attacks, undermining its protective role. Peppers should have at least 112 bits of strength (per NIST SP 800-63B, rev. 4, 2025) or 32 bytes (per IETF draft-ietf-kitten-password-storage-07, 2021) to resist brute-force attacks. Insider threats pose another concern, as authorized personnel with access to pepper storage could misuse it to facilitate unauthorized hash cracking. To mitigate these risks, organizations should implement regular pepper rotation, such as annually or upon suspicion of , using schemes that allow gradual migration of hashes to new values without immediate disruption, though this often requires planning for user password resets. Employing hardware security modules (HSMs) provides isolation by keeping the pepper within tamper-resistant hardware, preventing extraction even under physical attack. Access controls further reduce insider risks by enforcing least-privilege principles. Pepper-specific derivation techniques, such as using the pepper as a key in an before applying the primary hashing algorithm (e.g., bcrypt(base64([HMAC](/page/HMAC)-SHA384(password, pepper)), salt, cost)), help limit exposure by ensuring the pepper influences computation without direct reuse. According to guidelines, peppers should not be over-relied upon as a standalone defense; they supplement robust practices like adaptive hashing algorithms (e.g., or ) and user education on strong, unique passwords, rather than replacing them.

Best Practices and Applications

Recommendations

When implementing peppers in password hashing, adhere to NIST Special Publication 800-63B guidelines, which recommend using a secret input—known only to the verifier and functioning as a pepper—with at least 112 bits of strength, generated via an approved random bit generator. This secret should be applied through an additional iteration of a (KDF), such as with HMAC-SHA-256 (or HMAC-SHA-3 where supported for enhanced ), with a cost factor as high as practical to balance and performance; advises at least 600,000 iterations for PBKDF2-HMAC-SHA-256 on modern hardware. Peppers must be stored separately from the hashed passwords, ideally in a (HSM) or secure vault, to prevent exposure during database breaches. OWASP best practices emphasize combining peppers with unique per-user salts to thwart and offline brute-force attacks, applying the pepper either by prepending it to the salted password before the primary hash or by post-hashing the result with an using the pepper as the key. For large-scale systems, a shared application-wide pepper suffices for most cases, but unique peppers per user or per subset of users can provide compartmentalization against partial compromises, though this increases management complexity. Integrate peppers into adaptive hashing schemes like Argon2id (with parameters such as 19 MiB memory, 2 iterations, and 1 thread for parallelism per OWASP) or to dynamically adjust computational costs, ensuring the overall scheme meets at least 112 bits of security. In general, generate peppers randomly with high (at least 128 bits recommended for future-proofing) using cryptographically secure pseudorandom number generators, and regularly access controls to the storage mechanism to detect unauthorized retrieval. implementations for side-channel vulnerabilities, such as timing attacks, by ensuring constant-time operations during hashing and verification. Avoid custom cryptographic code; instead, leverage vetted libraries like libsodium's crypto_pwhash , which supports incorporating a pepper by deriving from the combined and secret inputs. As of 2024-2025, incorporate quantum-resistant considerations by favoring memory-hard functions like Argon2id, which resist attacks better than CPU-bound alternatives, and consider doubling iteration counts or using longer hash outputs (e.g., 512 bits) to maintain preimage resistance against quantum speedup. Following a breach involving pepper exposure, rotate the pepper immediately and enforce password resets for affected users, as rehashing without originals is infeasible.

Real-World Examples

One prominent real-world implementation of a secret pepper is found in 's password storage system. Dropbox first applies SHA-512 to user passwords, then uses (cost 10) to hash the result combined with per-user salts, and finally encrypts the bcrypt hash using AES-256 with a secret key known as the pepper, which is stored separately from the database to hinder attacker access. This layered approach was introduced to bolster security following past incidents, such as the 2012 breach, by ensuring that even if hashed passwords are compromised, the pepper's secrecy prevents efficient offline cracking. Cloud services and open-source tools have similarly incorporated peppers to strengthen credential protection. For instance, while specific details vary, identity management systems in environments often employ peppers alongside salts to protect against database dumps, aligning with broader industry practices for resilient . In modern usage from 2023 to 2025, peppers support compliance with frameworks like GDPR and HIPAA by providing robust technical measures for protecting including secrets. The 2017 NIST guidelines explicitly recommend incorporating input like a pepper during password hashing to enhance resistance to attacks beyond salting alone. Data breaches involving exposed credentials underscore the protective value of peppers in rendering stolen hashes unusable without the secret value, thereby limiting damage and preventing widespread account takeovers. Lessons from these deployments demonstrate that peppers can significantly delay cracking attempts in breach scenarios by requiring attackers to obtain or guess the secret key, often extending protection timelines from days to months depending on the system's design and computational resources. This aligns with recommendations for using peppers as an additional defense layer in production environments.

References

  1. https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
  2. https://www.ietf.org/archive/id/draft-ietf-kitten-password-storage-04.html
  3. https://www.cs.cornell.edu/fbs/publications/chptr.AuthPeople.pdf
  4. https://www.cs.arizona.edu/sites/default/files/TR94-34.pdf
  5. https://shiftleft.com/mirrors/www.hpl.hp.com/techreports/Compaq-DEC/SRC-TN-1997-033.pdf
  6. https://pages.nist.gov/800-63-4/sp800-63b.html
  7. https://csrc.nist.gov/glossary/term/salt
  8. https://seclists.org/bugtraq/1995/Apr/143
  9. https://www.sciencedirect.com/science/article/pii/016740489600003X
  10. https://www.usenix.org/legacy/events/sec99/full_papers/kedem/kedem.pdf
  11. https://pages.nist.gov/800-63-3/sp800-63b.html
  12. https://csrc.nist.gov/pubs/sp/800/63/b/4/final
  13. https://datatracker.ietf.org/doc/html/draft-ietf-kitten-password-storage-07#section-4.2
  14. https://security.stackexchange.com/questions/41754/what-is-the-purpose-of-a-pepper
  15. https://datatracker.ietf.org/doc/html/draft-ietf-kitten-password-storage-07#section-4.3
  16. https://ebac2018.sites.pomona.edu/classes/cs181s/2020fa/lectures/15-passwords/passwords.pdf
  17. https://www.cs.cornell.edu/courses/cs513/2007fa/hw.03.passwords.html
  18. https://datatracker.ietf.org/doc/html/draft-ietf-kitten-password-storage-07
  19. https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf
  20. https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html
  21. https://libsodium.gitbook.io/doc/password_hashing
  22. https://specopssoft.com/blog/post-quantum-cryptography-passwords/
  23. https://dropbox.tech/security/how-dropbox-securely-stores-your-passwords
Add your contribution
Related Hubs
User Avatar
No comments yet.