Why do password hashes need salt and pepper instead of relying on the hash alone?

Why This Matters for Security Teams

Passwords are rarely attacked one at a time. Once an attacker steals a database, the real risk is bulk cracking, reuse discovery, and credential stuffing across other services. A hash alone can still be fast to test at scale if the password set is weak or common. That is why modern guidance treats salting as a baseline control and peppering as an added defence when the threat model includes database exposure and offline cracking.

NIST’s NIST Cybersecurity Framework 2.0 emphasises reducing the impact of compromised credentials, while NHIMG research shows why that matters operationally: 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and 79% of organisations have experienced secrets leaks. The same failure pattern applies to password stores when teams assume the hash itself is enough.

In practice, many security teams discover the weakness of unsalted or poorly protected hashes only after a breach has already turned into a large-scale offline cracking exercise.

How It Works in Practice

A salt is a unique, per-password value stored alongside the hash. Its job is not secrecy but uniqueness. Two users with the same password should never produce the same stored result, and attackers should not be able to use precomputed rainbow tables across an entire database. A strong password hashing scheme such as Argon2, bcrypt, or scrypt also slows each guess, which raises attacker cost further.

A pepper is different. It is a separate secret that is not stored with the password records, ideally kept in a hardened application secret store or hardware-backed secret manager. If the password database is stolen without the pepper, cracking becomes materially harder because the attacker lacks the full input needed to validate guesses. This is why the pepper must be managed like a high-value secret, with strict access controls, rotation planning, and recovery procedures.

• Use a unique salt for every password, even if two users choose the same password.
• Choose an adaptive password hashing function rather than a fast general-purpose hash.
• Keep the pepper outside the database and outside application code.
• Limit which services can read the pepper and log every access.
• Plan for pepper rotation before an incident, because rotation can force password re-verification.

NHIMG’s Ultimate Guide to NHIs is useful here because it frames secrets protection as a lifecycle issue, not just a storage issue. Password protection fails when the secret material is spread across code, config, and infrastructure, which is exactly the problem highlighted by the Cisco Active Directory credentials breach research. These controls tend to break down when legacy systems require reversible password handling or when application teams cannot isolate the pepper from the database layer because of tightly coupled deployment design.

Common Variations and Edge Cases

Tighter password protection often increases operational overhead, requiring organisations to balance breach resistance against recovery complexity and application compatibility. That tradeoff is real, especially for older platforms, but it does not remove the need for salt and pepper where the architecture allows it.

Current guidance suggests that salting should be universal, while peppering is an additional control best used when the database may be exposed and the application can reliably protect an external secret. There is no universal standard for pepper placement yet. Some teams store it in an HSM or managed secret store, while others keep it in an application environment variable backed by stronger host controls. The security value depends on whether the pepper is actually separated from the compromised datastore.

Edge cases matter. Password reset flows, account migration, and hash algorithm upgrades can all complicate pepper use. If the pepper changes, every affected password generally needs revalidation or reset support. That is why peppering works best when the organisation can tolerate stronger operational controls around secret management and incident recovery. The broader lesson from NHI governance is the same: once a credential becomes a stored secret, its protection depends on isolation, rotation, and access discipline, not on the hash function alone.

Related resources from NHI Mgmt Group

• Why do unsalted password hashes remain risky even when the hash function is strong?
• Why do AI agents need a harness instead of relying on the model alone?
• Why do organisations need guardrails and regulation around generative AI instead of relying on model behaviour alone?
• Why do organisations use OV or EV certificates instead of relying on DV alone?