What Is Password Salting? Salt and Hash Explained Simply

When security researchers talk about protecting stored passwords, two words come up constantly: salting and hashing. You’ll usually hear them together — “passwords are salted and hashed” — but most explanations stop there without actually explaining what that means or why both steps matter.

This guide fixes that. We’ll cover what password salting is, why it exists, how it works alongside hashing, and what happens to password security when salting is skipped. No jargon, no unnecessary complexity — just a clear explanation of one of the most important ideas in application security.

If you’re still building up your understanding of hashing in general, our beginner’s guide to MD5 and how hash generators work is a good place to start before reading this one.

What Is Password Salting?

Password salting is the practice of adding a unique, randomly generated string to each password before it gets hashed and stored. That random string is the “salt.”

Think of it like this: if two people both use the password “sunshine” and there’s no salting, both their stored hashes will be identical. Anyone looking at the database can immediately see that two accounts share a password — and if one gets cracked, the other falls automatically. Salting eliminates this problem by making every stored hash unique, even when the underlying passwords are the same.

The salt itself isn’t secret — it’s stored right alongside the hash in the database. Its value comes not from secrecy but from uniqueness. Because every password gets a different salt, an attacker can’t take shortcuts. They have to crack each password one at a time, which is exactly what you want.

Why Salting Was Invented — The Rainbow Table Problem

To understand why password salting matters, you need to understand the attack it was designed to stop: the rainbow table attack.

A rainbow table is a precomputed database of password hashes. Before rainbow tables, cracking hashed passwords meant hashing guesses one at a time and comparing — a process that took significant computing time. Someone clever realized you could do all that computation in advance, store the results in a massive table, and then look up any hash instantly instead of computing it on the fly.

Here’s what that looks like in practice:

Rainbow Table (partial example — MD5, no salt):
───────────────────────────────────────────────────────
Password          MD5 Hash
───────────────────────────────────────────────────────
password          5f4dcc3b5aa765d61d8327deb882cf99
password123       482c811da5d5b4bc6d497ffa98491e38
123456            e10adc3949ba59abbe56e057f20f883e
qwerty            d8578edf8458ce06fbc5bb76a58c5ca4
iloveyou          f25a2fc72690b780b2a14e140ef6a9e0
───────────────────────────────────────────────────────

With a table like this, cracking a stolen hash database is trivial. The attacker doesn’t even need to “compute” anything — they just search. Tables covering hundreds of millions of common passwords have existed for years and are freely downloadable.

Salting destroys this attack completely. When every password has a unique random salt before hashing, the precomputed table becomes useless. “password” + “xK9mL2” produces a hash that no rainbow table has ever included, because that specific combination has never been precomputed. The attacker is back to brute force — one guess at a time. We explained why that matters in our password hash generator guide, specifically around the speed comparison between fast and slow algorithms.

How Password Salting Works — Step by Step

Here’s the exact process a properly built system uses when you set a new password:

Step 1: You set a password
──────────────────────────
  Input: "MyDogIsNamed$parky99"

Step 2: A unique salt is generated for your account
─────────────────────────────────────────────────────
  Salt: "r7Tn9KqWx3"   (random, generated fresh for you)
  (Different user, same password → different salt every time)

Step 3: Password + salt are combined
──────────────────────────────────────
  Combined: "MyDogIsNamed$parky99" + "r7Tn9KqWx3"

Step 4: The combined string is hashed
──────────────────────────────────────
  Hash("MyDogIsNamed$parky99r7Tn9KqWx3") → [unique hash]

Step 5: Salt + hash are stored in the database
────────────────────────────────────────────────
  Database record: { salt: "r7Tn9KqWx3", hash: "[unique hash]" }
  OR (with bcrypt/Argon2): salt is embedded inside the hash string

Step 6: Login verification
───────────────────────────
  You type your password → system retrieves your salt →
  combines + hashes → compares to stored hash → match = login ✓

The key insight at Step 5: with modern algorithms like bcrypt and Argon2id, the salt is automatically embedded inside the final hash string. You don’t store them separately — the algorithm handles it internally and produces a single output that contains everything needed for future verification.

Salt Length and Randomness — Why Both Matter

Not all salts are equally effective. A good salt needs to be two things: long enough and truly random.

Salt Quality Comparison:
──────────────────────────────────────────────────────────
Salt Type         Example          Problem
──────────────────────────────────────────────────────────
Too short         "xK"             Easy to precompute
Predictable       username + "1"   Attacker can anticipate
Non-random        incrementing ID  Pattern = reduced security
Good salt         128-bit random   Unique, unpredictable, safe
──────────────────────────────────────────────────────────

A short or predictable salt doesn’t fully defeat rainbow tables — it just means the attacker needs a slightly bigger one. A truly random 128-bit salt (which modern algorithms generate automatically) makes precomputed attacks completely impractical, because the search space becomes astronomically large.

This is one reason why writing your own salting logic is risky. Developers sometimes reach for predictable values like usernames, email addresses, or timestamps as salts. These are patterns that attackers can account for. Let the algorithm handle salting — bcrypt and Argon2 both do this correctly by default.

Salting vs. Peppering — What’s the Difference?

Once you understand what is salting in password security, you’ll sometimes encounter a related concept called peppering. Here’s a clear comparison:

Salt vs Pepper:
──────────────────────────────────────────────────────────────────
Property          Salt                    Pepper
──────────────────────────────────────────────────────────────────
Unique per user   Yes                     No — same for all users
Where stored      In the database         In server config / code
Secret?           No — stored openly      Yes — must stay secret
If DB leaked      Attacker sees salts     Pepper not in DB
Purpose           Defeats rainbow tables  Extra layer if DB leaked
──────────────────────────────────────────────────────────────────

A pepper is a secret string added to all passwords — stored in server configuration rather than the database. This means that even if an attacker steals the password database, they still don’t have the pepper, making offline cracking harder.

Peppering is optional and advanced. Password salting is not optional — it should always be present. For most systems, bcrypt or Argon2id with built-in automatic salting is the right place to start.

What Happens Without Salting — Real Consequences

When a database of unsalted MD5 hashes is leaked, automated tools can crack a significant percentage of the passwords within hours. Here’s why:

Attack Against an Unsalted Hash Database:
──────────────────────────────────────────────────────────
1. Attacker downloads leaked database
2. Looks up each hash in a precomputed rainbow table
3. Common passwords cracked instantly (no computation)
4. Remaining hashes cracked with dictionary attacks
5. Result: most accounts compromised within hours

Attack Against a Properly Salted + Bcrypt Database:
──────────────────────────────────────────────────────────
1. Attacker downloads leaked database
2. Rainbow tables → completely useless (unique salts)
3. Must brute-force each hash individually
4. Bcrypt at cost 12 → ~400ms per guess per hash
5. Result: cracking is computationally impractical at scale
──────────────────────────────────────────────────────────

The difference between these two outcomes is password salting combined with a slow algorithm. Neither alone is sufficient — a slow algorithm without salting still exposes common passwords to rainbow tables, and salting with a fast algorithm like MD5 still allows rapid brute force. You need both, which is exactly what bcrypt and Argon2 provide automatically.

We covered why MD5’s speed makes it dangerous in our explanation of why MD5 is no longer secure and our full comparison of MD5 vs SHA-256 vs Bcrypt.

Which Algorithms Handle Salting Automatically?

Algorithm         Auto-Salting    Salt in Output    Notes
──────────────────────────────────────────────────────────────
Bcrypt            Yes             Yes               Salt embedded in hash
Argon2id          Yes             Yes               Salt embedded in hash
PBKDF2            Partial*        Separately        Must pass salt manually
SHA-256           No              No                You must add salt yourself
MD5               No              No                Unsuitable for passwords
──────────────────────────────────────────────────────────────
* PBKDF2 requires you to generate and store the salt yourself

Bcrypt and Argon2id are the cleanest choices because they handle everything in one function call. The output string includes the algorithm version, cost factor, salt, and hash — all packed into a single portable value that contains everything needed for future verification.

If you’re working in PHP, this maps directly to password_hash() with PASSWORD_BCRYPT or PASSWORD_ARGON2ID — the salt generation and embedding happen automatically, and you never need to touch it manually. We covered the exact PHP implementation with copy-paste code in our PHP password hash guide.

What OWASP and NIST Say About Salting

Both of the most authoritative sources on application security are explicit about salting requirements.

The OWASP Password Storage Cheat Sheet states that every password must be hashed with a unique salt, and that the salt must be generated using a cryptographically secure random number generator. It specifically warns against using predictable values like usernames or timestamps as salts, because these reduce the randomness that makes salting effective.

OWASP Salting Requirements (from Password Storage Cheat Sheet):
──────────────────────────────────────────────────────────────────
Salt length:    At minimum 32 bytes (256 bits recommended)
Salt source:    Cryptographically secure random number generator
Salt scope:     Unique per user, per password
Salt storage:   Alongside the hash (bcrypt/Argon2 embed it)
Manual salting: Not required when using bcrypt or Argon2
Source:         cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
──────────────────────────────────────────────────────────────────

NIST Special Publication 800-63B-4 — the US government’s digital identity guidelines — takes the same position. It requires that stored passwords be salted with a value unique to each credential, using a salt of at least 32 bits. It also specifies that the salt must be chosen arbitrarily (randomly) to minimize collisions among stored hashed values.

Together, these two sources make it clear: salting isn’t optional. Any system that stores passwords without unique salts is out of compliance with both industry best practice and US federal security standards.

Salting in bcrypt and Argon2 — How It Looks in the Output

One reason developers sometimes ask whether they need to “add a salt” to bcrypt is that the process is invisible — it happens inside the function. But the salt is actually right there in the output string if you know where to look:

Bcrypt output string breakdown:
$2b $ 12 $ LQv3c1yqBWVHxkd0LHAkCO Yz6TtxMQJqhN8/lewmMliV9IFBnYhDK
 │    │    │──────────────────────│ │────────────────────────────────│
 │    │    └── Salt (22 chars)    └── Hash (31 chars)
 │    └── Cost factor (12)
 └── Algorithm version (2b)

Argon2id output string:
$argon2id$v=19$m=65536,t=3,p=4$[salt_base64]$[hash_base64]
           │    │                │              │
           │    └── Parameters   └── Salt       └── Hash
           └── Version

Everything needed to verify the password later — the algorithm, the settings, the salt, and the hash — is packed into that one string. This is called a PHC string format and is exactly what makes modern password hashing so portable and future-proof.