Skip to main content
Identity Authority
Category: Passwords & Hashing

Peppering

Also known as: Pepper
Simply put

Peppering is a technique used when storing passwords in which a secret value is added to a password before it is scrambled (hashed) into a stored form. Because this secret value is kept separate from the stored passwords, it makes it harder for an attacker to reverse the stored data back into usable passwords even if they steal the password database.

Formal definition

Peppering is the practice of incorporating a secret value (the pepper) into a password prior to hashing with a cryptographic hash function. Unlike a salt, which is typically stored alongside the hashed password and is intended to be unique per credential to defeat precomputed-table and cross-account attacks, a pepper is a secret that is not stored with the password hash; in most deployments it is held separately, for example in application configuration or a hardware/key management module. Its security benefit depends on the pepper remaining confidential, so its effectiveness is contingent on that secret not being compromised together with the credential store. Specifics such as pepper length, how it is combined with the password, and where the secret is managed vary by implementation and are out of scope for this definition. Note that the surrounding evidence includes unrelated non-cryptographic senses of the term (labor organizing, volleyball), which do not apply here.

Why it matters

Password database breaches remain one of the most common and damaging events in identity systems, and the strength of stored credentials often determines how much damage a breach causes. Salting is standard practice to defeat precomputed-table (rainbow table) attacks and to ensure that identical passwords do not produce identical hashes across accounts, but salts are typically stored alongside the hashes and are therefore compromised together with the credential store. Peppering adds a secret value that, by design, is not stored with the hashes, so an attacker who exfiltrates only the credential database does not necessarily obtain everything needed to mount efficient offline cracking.

The value of peppering is entirely contingent on the pepper remaining confidential. If the secret is held separately, for example in application configuration or a hardware or key management module, then a database-only breach leaves the attacker missing a component required to validate guesses at scale. This is why peppering is best understood as a defense-in-depth measure layered on top of salting and a strong, deliberately slow password hashing function, rather than a replacement for either.

The corresponding limitation matters just as much for architects to understand: if the pepper is compromised together with the credential store, for instance because it lives in the same repository or is exposed through the same application vulnerability, its protective benefit is lost. Peppering therefore shifts a meaningful part of the threat model onto secret management, and decisions about where and how the pepper is stored are as security-relevant as the choice to pepper at all.

Who it's relevant to

Security architects
Architects deciding how credentials are stored should weigh peppering as a defense-in-depth layer on top of per-credential salting and a slow password hashing function. The key design decision is where the pepper lives: keeping it separate from the credential store, such as in a hardware or key management module, is what preserves its benefit when a database is breached.
IAM and application engineers
Engineers implementing password storage need to distinguish a pepper from a salt: the salt is typically unique per credential and stored with the hash, while the pepper is a secret combined with the password before hashing and held separately. Getting the secret-management side right is essential, since the pepper provides no benefit if it is exposed alongside the credentials it protects.
Compliance and audit leads
Reviewers assessing credential-storage controls should verify not only that salting and an appropriate hashing function are used, but also, where peppering is claimed, that the pepper is genuinely stored separately from the password database. A pepper co-located with the credential store does not deliver its intended protection.

Inside Peppering

Pepper (secret)
A site-wide secret value that is combined with a password (and typically its per-user salt) before hashing. Unlike a salt, the pepper is not stored alongside the hashed password in the credential database.
Separation from the credential store
The defining characteristic of peppering is that the pepper is held outside the database that contains the password hashes, for example in an application configuration secret, a hardware security module (HSM), or a dedicated secrets manager, depending on the deployment.
Application method
The pepper can be applied by concatenating it with the password prior to hashing, or, in more robust designs, by using it as a key in a keyed function such as an HMAC over the password. The keyed approach lets the pepper live inside an HSM without ever leaving it.
Relationship to salting
Peppering is intended to complement, not replace, per-user salting. Salts are unique per credential and stored with the hash to defeat precomputation across accounts; the pepper is a shared secret kept separate to raise the cost of an offline attack if the database alone is compromised.
Threat model addressed
Peppering primarily targets the scenario of a database-only breach: if an attacker obtains the password hashes and salts but not the pepper, brute-force and dictionary attacks are impeded because a critical secret is missing.

Common questions

Answers to the questions practitioners most commonly ask about Peppering.

Is peppering just another name for salting?
No. Salting and peppering are distinct techniques that are often combined rather than interchangeable. A salt is a unique, random value generated per credential and typically stored alongside the hash in the same datastore; its purpose is to ensure identical passwords produce different hashes and to defeat precomputed lookup (rainbow) tables. A pepper is a secret value that is not stored with the hash and is typically kept separate from the credential database, so that an attacker who obtains the database still lacks a component needed to validate or crack the hashes. In most deployments the two are used together: the salt provides per-credential uniqueness, while the pepper adds a secret that resists offline attacks against a leaked database.
Does peppering replace the need for a strong password hashing function?
No. A pepper is a supplementary defense, not a substitute for a deliberately slow, memory-hard password hashing function. The underlying algorithm still governs how expensive each guess is for an attacker who has obtained the necessary material. Peppering adds value primarily in the scenario where the credential store is leaked but the pepper secret is not, since the attacker then lacks an input required to test guesses. If both the hashes and the pepper are compromised together, the pepper provides little additional protection, so it should be layered on top of, not in place of, an appropriately configured hashing function and per-credential salting.
Where should the pepper be stored so it is separated from the hashed credentials?
The core requirement is that the pepper reside in a different trust boundary from the credential database, so that a compromise of the database alone does not expose it. Depending on configuration, common approaches include storing the pepper in application configuration or environment variables held on the application tier, in a dedicated secrets manager, or in a hardware security module (HSM) or key management service. Where an HSM or KMS performs the pepper operation, the secret can remain within that boundary and never reach the credential store. The suitability of each approach depends on your threat model and operational constraints, and this entry does not endorse a specific vendor mechanism.
How is a pepper applied during the hashing process?
Implementations vary, but the pepper is generally incorporated as an additional secret input alongside the password and salt before or during hashing. Two commonly described patterns are combining the pepper with the password input to the password hashing function, or applying a keyed operation such as an HMAC using the pepper as the key, either before or after the primary hash. When the pepper functions as a key to a keyed construction handled by an HSM or KMS, the secret can stay inside that boundary. The exact construction should be chosen to keep the pepper out of the credential store and to remain compatible with your hashing function; specifics depend on the libraries and platform in use.
How do you rotate a pepper without invalidating existing stored hashes?
Pepper rotation is nontrivial because the secret is an input to hashes that cannot be recomputed without the original password. A frequently described approach is to version peppers and record which pepper version produced each stored hash, so multiple peppers can be valid simultaneously. New and re-hashed credentials use the current pepper, while existing records continue validating against their recorded version, typically being upgraded to the new pepper on the user's next successful authentication when the plaintext is briefly available. Retiring an old pepper generally requires that all records using it have been migrated first. The feasibility and detail of this process depend on your storage schema and operational tooling.
How does peppering affect authentication verification at login time?
At verification, the same pepper that was used when the credential was created must be available and applied to the submitted password using the identical construction, along with the stored salt, to reproduce the hash for comparison. This means the pepper secret must be reachable by the component performing the check, which is why it typically lives on the application tier or within an HSM or KMS rather than in the credential database. If the pepper is unavailable or a versioned pepper is mismatched, verification will fail even for correct passwords, so availability and correct version tracking of the pepper are operational prerequisites. Peppering concerns the credential verification step only and does not by itself address authorization decisions that follow authentication.

Common misconceptions

A pepper is just another name for a salt.
They serve different purposes. A salt is unique per credential and stored with the hash to prevent precomputation and hash reuse across accounts; a pepper is typically a shared secret kept outside the credential store to protect against a database-only compromise. In most deployments the two are used together, not interchangeably.
Peppering makes password hashes effectively unbreakable.
Peppering only adds protection while the pepper remains secret and separate from the hashes. If an attacker compromises both the database and the location holding the pepper, the additional protection is lost, and peppering does not substitute for a strong, slow password hashing function and per-user salts.
Peppering is a standardized, universally implemented mechanism.
Peppering is a design technique rather than a single standardized construct, and its exact application, storage, and use of keyed functions vary by implementation and deployment context. Whether and how it helps depends heavily on where the pepper is stored and how it is applied.

Best practices

Always pair peppering with per-user salting and a strong, deliberately slow password hashing function; treat the pepper as an additional layer rather than a replacement for either.
Store the pepper separately from the credential database, for example in an HSM, secrets manager, or application configuration that is not co-located with the password hashes.
Prefer a keyed construction such as an HMAC over plain concatenation where feasible, so the pepper can remain inside an HSM and never be exposed alongside the hashes.
Plan for pepper rotation, recognizing that changing the pepper affects verification of all existing credentials and typically requires a migration or versioning strategy.
Restrict and audit access to the pepper as tightly as any other high-value secret, since its protection value depends entirely on remaining confidential and separate from the credential store.
Document the threat model you are addressing (primarily a database-only breach) and do not assume peppering protects against a full compromise that also yields the pepper.
Promotional banner graphic asking if you are ready for PCI DSS 4.0 with a call-to-action to get the guide