What is a salt in password hashing, why is it used, and what is a pepper?
Short answer
A salt is a unique, random value generated per user and combined with the password before hashing. It ensures identical passwords produce different hashes and makes precomputed attacks like rainbow tables useless, since the attacker would need a separate table per salt. Salts are stored alongside the hash. A pepper is an additional secret value, the same for all users, kept separately (e.g., in app config or an HSM) so a database leak alone isn't enough.
This question separates candidates who know the words from those who understand which attack each defense stops. Salting and peppering target different threats, and saying so precisely is what earns the point.
What a salt defends against
Without a salt, the same password always hashes to the same value. Two consequences follow. First, attackers can precompute rainbow tables — huge lookup tables of hash-to-password — and crack any unsalted hash by lookup. Second, if two users share a password, their identical hashes reveal that fact in a leaked database.
A salt is a unique, random value generated per user and mixed into the password before hashing. Now identical passwords produce different hashes, so a precomputed table is worthless — an attacker would need a fresh table per salt, which defeats the economics entirely. The salt is not secret; it's stored right next to the hash and that's fine, because its job is to make each hash unique, not to be hidden.
What a salt does not do
Salting does not meaningfully slow down a brute-force attack against a single targeted hash — the attacker just includes the known salt while guessing. That's why salting must be paired with a slow hashing function (bcrypt, scrypt, Argon2). Salt stops bulk precomputation; work factor stops fast guessing.
What a pepper adds
A pepper is an additional secret value mixed in during hashing, but unlike the salt it is the same for all users and stored separately from the database — in application config, an environment variable, or ideally a hardware security module. The point is defense in depth: if only the password database leaks, the attacker is missing the pepper and cannot verify guesses offline. It only helps if it is genuinely kept apart from the hashes.
What interviewers look for
Per-user uniqueness, the rainbow-table and identical-hash rationale, the fact that salts can be public while peppers must be secret and separate, and the caveat that salting alone doesn't stop targeted brute force.
Likely follow-ups
- Why is it safe to store the salt next to the hash, but not the pepper?
- Does salting slow down a targeted brute-force attack against one user?
- Why do salts need to be unique per user rather than one global salt?