Salting

Salting is a cryptographic technique for protecting stored passwords. When a system stores a password, it should never keep the plain text; instead it stores a hash — the output of a one-way function that is easy to compute from the password but very hard to reverse. Salting improves this by generating a unique, random string called a salt for each password, combining that salt with the password, and then hashing the combined value. The salt is stored alongside the resulting hash, usually in the clear, because its job is not to be secret but to be unique. When a user logs in, the system retrieves that user's salt, combines it with the entered password, hashes the result, and checks whether it matches the stored hash. The salt is typically produced by a cryptographically secure random generator so it cannot be predicted.

The reason salting matters is that unsalted hashes are dangerously weak against precomputed attacks. Without a salt, two users with the same password produce the same hash, so an attacker who cracks one has cracked them all, and attackers can use rainbow tables — enormous precomputed lookups of hash-to-password mappings — to reverse common hashes instantly. A unique salt per password breaks both problems: identical passwords now produce completely different hashes, so a single crack no longer generalizes, and precomputed tables become useless because they would have to be rebuilt for every possible salt. Salting does not make a weak password strong, but it makes a leaked password database far more expensive and slow to crack, buying time and protecting the many users who reused a common password.

Salting is easy to confuse with the operations around it. Hashing is the underlying one-way transformation that turns a password into a fixed-length value that cannot be practically reversed; salting is not a replacement for hashing but an addition to it — you salt and then hash. So hashing is the lock, and salting makes every lock unique. A related but distinct idea is peppering. A pepper is also secret data mixed into the password before hashing, but unlike a salt it is a single value kept secret and stored separately from the database — often in application code or a hardware module — rather than a unique value stored beside each hash. A salt defends against precomputed attacks; a pepper adds a secret an attacker who steals only the database does not have.

The practical distinction is where the value lives and what it defends against. A salt is unique per password and stored with the hash, and its purpose is to defeat rainbow tables and prevent one crack from breaking many accounts — it does not need to be secret. A pepper is shared, secret, and stored apart, and its purpose is to add a factor an attacker who exfiltrates the password table alone still lacks. Modern password storage often uses a purpose-built key-derivation function such as bcrypt, scrypt, or Argon2, which build salting in and are deliberately slow to resist brute force. The takeaway is that salting is one essential layer — combined with strong hashing and, ideally, a slow key-derivation function — not a standalone fix.

Salting well means generating a fresh, unique salt for every password using a cryptographically secure random generator, storing that salt alongside the hash, and using a strong, slow password-hashing function such as bcrypt, scrypt, or Argon2 that incorporates salting and resists brute-force cracking. The salt should be long enough to be effectively unique across all users and never reused between passwords, because a reused salt reintroduces the very weakness salting exists to remove. It is a foundational practice for any system that stores credentials, and it works quietly in the background — users never see it, but it is a major reason a leaked hash database is not an instant catastrophe for everyone in it.

The failure modes are storing unsalted hashes (leaving them open to rainbow-table attacks), reusing the same salt across users (so identical passwords still collide and precomputation partly returns), using a weak or predictable salt generator, and treating salting as a substitute for a slow hashing function rather than a companion to one. Another trap is thinking salting makes weak passwords safe — it does not; it protects the store, not the strength of the secret. The discipline is to salt uniquely and randomly, hash with a purpose-built slow function, and treat salting as one indispensable layer of credential protection, remembering that it raises the cost of cracking a stolen database rather than making passwords unbreakable.

Salting — adding a unique random string to each password before hashing — makes identical passwords hash differently and defeats rainbow-table and dictionary attacks, a foundational layer of credential protection.

Etymology: source.

Search interest for this term over the last five years:

View interest-over-time on Google Trends →

Areas of marketing where salting is a core concern: