Pepper

A pepper is a secret value added to passwords before hashing, but stored separately from the database. If the database is stolen without the pepper, offline cracking becomes far harder because the attacker does not have all the inputs needed to test guesses.

Expanded Definition

A pepper is not a password replacement or a hashing algorithm; it is a separate secret that strengthens password storage by adding an additional unknown input before or during hashing. Unlike a salt, which is typically stored alongside the hash, a pepper must remain outside the database and should be protected with stronger access controls.

In NHI security, the term matters because secrets are often distributed across applications, CI/CD tooling, vaults, and runtime environments, and the protective value of a pepper depends on whether it is isolated from those same failure points. Guidance is broadly consistent, but implementation details vary across vendors and architectures, so no single standard governs this yet. NIST’s NIST Cybersecurity Framework 2.0 reinforces the wider principle: protect credentials according to their exposure and impact, not just their format.

The most common misapplication is treating a pepper like a stored application setting in the same environment as the hash database, which occurs when teams assume “separate file” means “separate security boundary.”

Examples and Use Cases

Implementing a pepper rigorously often introduces key-management and recovery constraints, requiring organisations to weigh stronger offline resistance against operational complexity during rotation, restore, and incident response.

• A login service hashes passwords with a pepper held in an HSM, so a stolen user table is far less useful to an attacker without that second secret.
• An authentication platform rotates its pepper only during controlled maintenance windows, because changing it immediately would invalidate every stored password hash at once.
• A regulated SaaS team places the pepper outside the database and outside the CI/CD variable store, following the same separation mindset described in the Ultimate Guide to NHIs.
• A breach response team keeps the pepper in a dedicated secrets manager so that database-only exfiltration does not automatically enable offline password cracking.
• An architecture review compares peppering with rate limiting and MFA, using NIST Cybersecurity Framework 2.0 to ensure the password layer fits the broader control set.

In practice, definitions vary across vendors on whether the pepper is applied before hashing, keyed into an HMAC-style construction, or wrapped around the hash pipeline, but the security objective remains the same: keep one critical input hidden from bulk compromise. The Ultimate Guide to NHIs is useful here because the same secret-handling discipline applies to service accounts, API keys, and other machine identities.

Why It Matters in NHI Security

Peppering matters because attackers rarely need every control to fail; they only need one repository of secrets to become readable. When passwords, API keys, certificates, and other secrets are stored carelessly, the blast radius expands from one application to the identity layer itself. NHI programs are especially exposed because secrets are frequently copied into code, build systems, and runtime environments, making “separate from the database” an incomplete safeguard if the pepper is still discoverable.

NHI Mgmt Group reports that 91.6% of secrets remain valid five days after the targeted organisation is notified, which shows how slowly secret-related exposure is often remediated. That lag is exactly why pepper handling must be paired with disciplined rotation, access review, and containment under frameworks such as NIST Cybersecurity Framework 2.0. For broader NHI hygiene, the same source also documents how often credentials persist outside secure managers and how widely service-account visibility remains incomplete.

Organisations typically encounter the need to understand a pepper only after a password database is stolen and brute-force attempts begin, at which point the hidden secret becomes operationally unavoidable to address.