Salting in Security — 117M LinkedIn Unsalted Hashes

Every time you log in to a website, your password travels across a computer network and is checked against a stored password in a database. Developers have three choices for how to store that sensitive information: plaintext (catastrophic), hashed (vulnerable without salting), or salted and hashed (correct).

In 2012, LinkedIn's password database was breached — 117 million accounts. The hashed passwords were stored without salting, using unsalted SHA-1. Within days, security researchers cracked over 90% of them using pre-computed rainbow tables: databases mapping known hash values back to their original plaintext. The passwords had been hashed, technically, but without salting passwords the protection was nearly worthless.

The same year, Adobe lost 153 million records — also without proper salting. They used the same encryption key for all passwords, meaning cracking one user's stored password cracked every user with the same hint simultaneously.

Salting passwords is not a complicated concept — it is three lines of code. But failing to do it is one of the most common and consequential security mistakes in web development. I have audited six production systems in the last four years that stored unsalted MD5 or SHA-1 hashes. Six. In 2024. One of them was a fintech platform with 200,000 users. The CTO was shocked when I showed him that his entire user base could be cracked in GPU. He thought 'hashing' meant 'safe.' It doesn't — not without salting, not without a proper password hashing algorithm, and not without several other layers that this article will walk you through.

By the end you will understand exactly what password salting is, why it works, how to implement it correctly with bcrypt and Argon2, what a pepper adds on top of a salt, and the specific production mistakes that leave hashed passwords crackable even when developers think they've done everything right.

Why Unsalted Hashes Leak 117M Passwords

Salting means appending a unique, random value (the salt) to each password before hashing it. Without a salt, identical passwords produce identical hashes — an attacker who precomputes hashes for common passwords (rainbow table) can reverse them instantly. With a salt, every hash is unique even if two users pick the same password. The salt is stored alongside the hash, but it doesn't need to be secret — its job is to force attackers to crack each password individually. In practice, use a cryptographically random salt of at least 16 bytes per password. Never reuse salts across accounts. The 2012 LinkedIn breach exposed 117M unsalted SHA-1 hashes — attackers reversed 90%+ within days. A proper salt would have reduced that to near zero.

Hashing Without Salt — The Rainbow Table Problem

A hash function converts a password into a fixed-length hash value: SHA-256 (a secure hash algorithm) applied to 'password123' always produces the same 64-character hex string. This is deterministic — and that determinism is the vulnerability.

An attacker who steals your password database does not need to 'decrypt' anything. They have three escalating options:

Brute force attack: Try every possible character combination systematically. For short passwords, this is computationally feasible — an 8-character alphanumeric password has ~218 trillion combinations, but a GPU can try billions of SHA-256 hashes per second. With a modern GPU cluster, an 8-character password falls in hours.

Dictionary attack: Try every word in a wordlist, every common password, every leaked password from previous breaches. Most users choose common passwords — a dictionary attack of 1 billion entries takes seconds on a GPU. The Have I Been Pwned password list alone has over 800 million entries.

Rainbow table attack (the most devastating): Pre-compute a hash table mapping every common password and every string up to 8 characters to its SHA-256 hash value. This precomputed table costs computation time once but can be reused against any unsalted database forever. For each stolen hashed password in the database, a simple hash table lookup returns the plaintext in O(1) time. Rainbow tables don't even store every hash — they use chains of hash and reduction functions to compress precomputed tables into gigabytes rather than petabytes.

Without salting passwords, none of these attacks require cracking each account individually — the attacker runs the entire password database through a lookup against precomputed tables in minutes. I once ran a rainbow table lookup against a client's unsalted SHA-256 database of 85,000 users on a laptop. It took 14 seconds. Fourteen seconds to crack 85,000 passwords. That is what unsalted hashing buys you — essentially nothing.

import hashlib
import os

# CORRECT manual salting (for illustration — use bcrypt in production)
def hash_password(password: str) -> tuple[str, str]:
    # Generate a unique 32-byte random salt per user
    salt = os.urandom(32).hex()
    # Hash password+salt together
    digest = hashlib.sha256((password + salt).encode()).hexdigest()
    return digest, salt  # store BOTH in database

def verify_password(password: str, stored_hash: str, stored_salt: str) -> bool:
    digest = hashlib.sha256((password + stored_salt).encode()).hexdigest()
    return digest == stored_hash

# Same password → completely different hashes
hash1, salt1 = hash_password('password123')
hash2, salt2 = hash_password('password123')

print(f'Hash 1: {hash1[:32]}...')
print(f'Hash 2: {hash2[:32]}...')
print(f'Same?   {hash1 == hash2}')  # False — salts are different

# Verification works correctly
print(f'Correct password:   {verify_password("password123", hash1, salt1)}')  # True
print(f'Wrong password:     {verify_password("wrongpassword", hash1, salt1)}') # False

# ── WHY RAW SHA-256 + SALT IS STILL WRONG ────────────────────────────────────
# Even with a unique salt, SHA-256 is too fast.
# A single NVIDIA RTX 4090 can compute ~22 billion SHA-256 hashes per second.
# An 8-character password (95 possible chars)^8 = 6.6 quadrillion combinations.
# At 22 billion/sec, that's ~3.5 days for a single GPU.
# A botnet of 100 GPUs does it in under an hour.
# That is why you need bcrypt or Argon2 — not just a salt.

The Right Way: bcrypt, Argon2, PBKDF2

The salting example above still uses raw SHA-256 — a secure hash algorithm designed for speed and integrity, not password security. Speed is the enemy here: a GPU can try billions of SHA-256 hashes per second. Salting passwords with SHA-256 defeats rainbow table attacks but still leaves hashed passwords vulnerable to per-account brute force at enormous speed.

The best practices solution is not just salting but using a dedicated password hashing function designed from the ground up for password security:

1. Handles salting automatically — generates and stores the unique salt value internally in the hash string
2. Is deliberately slow — configurable work factor that can be tuned as hardware gets faster, keeping brute force attacks expensive
3. Is memory-hard (Argon2) — requires large RAM per attempt, making GPU and ASIC attacks impractical

bcrypt: The battle-tested default for password salting. Cost factor of 12 takes ~250ms per hash — imperceptible to users, brutal for attackers trying billions of guesses. Each bcrypt output embeds the unique salt value, work factor, and algorithm version. I have used bcrypt in production for over a decade across banking, healthcare, and e-commerce platforms. It has never been the bottleneck. Ever. If someone tells you bcrypt is 'too slow for login,' they are either using an absurdly high cost factor or their database query is the real bottleneck and they're blaming the hash.

Argon2id: Winner of the 2015 Password Hashing Competition. Memory-hard: an attacker needs gigabytes of RAM per guess. The modern best practices recommendation for new systems. If you are starting a new project in 2026, use Argon2id. If you have an existing bcrypt system, there is no urgent reason to migrate — bcrypt with cost factor 12+ is still secure.

PBKDF2-SHA256: The secure hash algorithm SHA-256 iterated 100,000+ times with a unique salt. FIPS-approved. Django's default password security mechanism. Weakest of the three because it is not memory-hard — a GPU can still parallelise PBKDF2 efficiently — but it meets compliance requirements for government and financial systems.

What I tell every team: Use bcrypt if you want something that just works and has 20 years of battle-testing. Use Argon2id if you are building a new system and want the strongest theoretical protection. Use PBKDF2 only if compliance requires it. Never use raw SHA-256, MD5, or SHA-1 for passwords. Not even with a salt. Not even with a pepper. Not even with a cost factor. Those algorithms were not designed for password storage.

# pip install bcrypt argon2-cffi
import bcrypt
from argon2 import PasswordHasher
from argon2.exceptions import VerifyMismatchError

# ── bcrypt ──────────────────────────────────────────────────────
# bcrypt handles salting internally — you never manage the salt yourself.
# The output string contains: algorithm + cost factor + salt + hash
# Format: $2b$12$EixZaYVK1fsbw1ZfbX3OXePaWxn96p36WQoeG6Lruj3vjPGga31lW
#         ^^^ ^^
#         |   |-- cost factor (2^12 = 4096 rounds of key expansion)
#         |------ algorithm version (2b = current bcrypt)

def bcrypt_hash(password: str) -> bytes:
    # bcrypt generates and embeds the salt automatically
    return bcrypt.hashpw(password.encode(), bcrypt.gensalt(rounds=12))

def bcrypt_verify(password: str, hashed: bytes) -> bool:
    # bcrypt.checkpw extracts the salt from the stored hash,
    # re-hashes the input with that salt, and compares.
    # It uses constant-time comparison internally — no timing oracle.
    return bcrypt.checkpw(password.encode(), hashed)

hashed = bcrypt_hash('mysecretpassword')
print(f'bcrypt hash: {hashed}')
print(f'Verify correct:   {bcrypt_verify("mysecretpassword", hashed)}')
print(f'Verify incorrect: {bcrypt_verify("wrongpassword", hashed)}')

# ── Extracting the cost factor from a bcrypt hash ───────────────
def get_bcrypt_cost(stored_hash: str) -> int:
    """Parse the cost factor from a bcrypt hash string."""
    # bcrypt format: $2b$CC$...
    # CC is the cost factor as a 2-digit string
    try:
        return int(stored_hash[4:6])
    except (ValueError, IndexError):
        raise ValueError(f'Not a valid bcrypt hash: {stored_hash[:20]}...')

print(f'Cost factor: {get_bcrypt_cost(hashed.decode())}')  # 12

# ── Argon2id (recommended for new systems) ───────────────────────
# Argon2id parameters:
#   time_cost:    number of iterations (higher = slower, more secure)
#   memory_cost:  RAM in KiB required per hash (higher = more GPU-resistant)
#   parallelism:  number of threads (match your server's core count)
#   hash_len:     output hash length in bytes (32 is standard)
#   salt_len:     salt length in bytes (16 is standard, generated automatically)

ph = PasswordHasher(
    time_cost=2,         # 2 iterations
    memory_cost=65536,   # 64 MiB RAM per hash
    parallelism=2,       # 2 threads
    hash_len=32,         # 32-byte output
    salt_len=16,         # 16-byte salt (auto-generated)
)

def argon2_hash(password: str) -> str:
    return ph.hash(password)  # salt embedded in the hash string

def argon2_verify(password: str, stored_hash: str) -> bool:
    try:
        return ph.verify(stored_hash, password)
    except VerifyMismatchError:
        return False  # Wrong password
    except Exception:
        return False  # Corrupt hash or other error

arg_hash = argon2_hash('mysecretpassword')
print(f'\nArgon2 hash: {arg_hash}')
print(f'Verify correct:   {argon2_verify("mysecretpassword", arg_hash)}')
print(f'Verify incorrect: {argon2_verify("wrongpassword", arg_hash)}')

# ── Check if hash needs rehashing (algorithm upgrade) ───────────
def argon2_needs_rehash(stored_hash: str) -> bool:
    """Returns True if the stored hash uses outdated parameters."""
    return ph.check_needs_rehash(stored_hash)

# If you upgraded from time_cost=1 to time_cost=2:
# old_hash = $argon2id$v=19$m=65536,t=1,p=2$...
# argon2_needs_rehash(old_hash) → True (t=1 < t=2)

Hashing vs Salting vs Encryption — What Each One Does

These three terms are frequently confused. They serve different purposes and have different threat models. I have seen job candidates — and senior developers — use 'encryption' when they mean 'hashing' in technical discussions. The distinction matters because it determines what happens when your database is breached.

# Not executable — reference documentation for the comparison table above.
# Each concept has a fundamentally different security property:

# HASHING: one-way transformation. Cannot be reversed.
# Use case: file checksums, git commits, data integrity verification.
# Example: SHA-256('hello') always equals 2cf24dba5fb0a30e26e83b2ac5b9e29e...
# Vulnerability: deterministic — same input always produces same output.

# SALTING + HASHING: one-way transformation with per-user randomisation.
# Use case: password storage.
# Example: bcrypt('hello' + 'random_salt_1') ≠ bcrypt('hello' + 'random_salt_2')
# Strength: defeats rainbow tables, forces per-account cracking.

# ENCRYPTION: two-way transformation. Can the cost factor from be reversed with the key.
# Use case: storing data you need to retrieve (credit cards, PII, API keys).
# Example: AES-GCM.encrypt('4111111111111111', key) → ciphertext → decrypt(key) → plaintext
# Vulnerability: if the key is compromised, all encrypted data is recoverable.

# CRITICAL RULE: Never encrypt passwords.
# If your database AND your encryption key are both compromised (common in breaches),
# every password is immediately recoverable. Properly salted bcrypt hashes remain
# computationally infeasible to crack even with the full database.

Why Salting Defeats Rainbow Tables, Dictionary Attacks, and Brute Force

Understanding why password salting works requires understanding the three attack vectors it defeats:

Rainbow table attacks: An attacker pre-builds a massive hash table mapping common passwords and their variants to their hashed password values. Without salting, your entire database is vulnerable to a single lookup pass. With a unique salt value per user, the attacker would need a separate precomputed table for every possible salt — computationally infeasible. A single 16-byte salt value means there are 2^128 possible salts. Precomputed tables become worthless.

Dictionary attacks on a stolen database: Even without precomputed tables, an attacker can run a wordlist of common passwords through the hash function and compare against every stored hash simultaneously. Without salting, finding one match reveals the password for every user with that common password. With a unique salt per user, each stored hash must be attacked individually — the attacker cannot parallelise across users.

Brute force attacks: Systematic guessing of all possible passwords. Salting does not directly slow brute force (that is the job of bcrypt/Argon2's work factor). What salting does is prevent the attacker from amortising their brute force effort across all users simultaneously. Without a unique salt, cracking one password with a given hash value means cracking every user with that same hashed password.

What salting does NOT protect against: Salting alone does not protect against brute force attacks on individual accounts if you use a fast hash function like SHA-256. That is why best practices require a slow, memory-hard function (bcrypt, Argon2) in addition to a unique salt. Salting passwords and choosing a proper password hashing algorithm are complementary, not interchangeable defences.

Here is how I explain it to junior developers: salting is the lock on your front door. bcrypt/Argon2 is the reinforced steel frame. You need both. A lock without a reinforced frame can be kicked in. A reinforced frame without a lock is just a wall. And plaintext storage is leaving the door wide open with a sign that says 'please rob me.'

Production-Grade Password Storage — Beyond Just Salting

A production-grade password security system has several layers of best practices beyond just salting passwords.

Pepper: An additional secret value combined with the password and unique salt before hashing. Unlike the salt (stored in the database), peppers are NOT in the database — they live in application config or an HSM. Even if an attacker gets your entire database, they cannot crack hashes without the pepper.

Rehashing on login: When a user logs in successfully, check if their stored hash uses an outdated algorithm or work factor. If so, rehash with current settings and update the stored hash. This upgrades security without forcing password resets. Argon2 has a built-in check_needs_rehash() method. For bcrypt, parse the cost factor from the stored hash string and compare against your current target.

import bcrypt
import os

PEPPER = os.environ.get('PASSWORD_PEPPER', '')

def hash_password(password: str) -> bytes:
    return bcrypt.hashpw((password + PEPPER).encode(), bcrypt.gensalt(rounds=12))

def verify_password(password: str, stored: bytes) -> bool:
    return bcrypt.checkpw((password + PEPPER).encode(), stored)

def get_bcrypt_cost(h: str) -> int:
    return int(h[4:6])

def needs_rehash(h: str, target: int = 12) -> bool:
    return get_bcrypt_cost(h) < target

hashed = hash_password('mysecretpassword')
print(f'Stored: {hashed.decode()}')
print(f'Valid:  {verify_password("mysecretpassword", hashed)}')
print(f'Wrong:  {verify_password("wrongpassword", hashed)}')
print(f'Cost:   {get_bcrypt_cost(hashed.decode())}')
print(f'Rehash? {needs_rehash(hashed.decode())}')

How Salting Actually Works — The Five-Step Guts

Most explanations hand-wave this. Here's the raw flow, because you need to debug it when something breaks.

Step one: generate a cryptographically random salt. Not os.urandom(4). At least 16 bytes. Store it in plaintext alongside the hash — it's not secret, it's unique. Step two: concatenate the password and salt into a single input. The order matters; put the salt first to avoid length-extension attacks on older hash functions. Step three: hash the combined input using a slow, adaptive algorithm like bcrypt, PBKDF2, or Argon2. Step four: store the salt and the resulting hash in your database. Step five: on login, fetch the salt for that user, recombine it with the provided password, hash, and compare.

The salt makes the hash unique per user, even if their password is "password123". Without it, two identical passwords produce identical hashes — a dead giveaway that tells an attacker exactly which accounts to target first.

// io.thecodeforge — system-design tutorial

import os
import hashlib
import base64

def create_user_password(password: str, user_id: str) -> tuple:
    salt = os.urandom(16)
    # Combine salt and password; salt first is safer
    salted_input = salt + password.encode('utf-8')
    # Use PBKDF2 with 600k iterations (OWASP 2023 recommendation)
    hash_bytes = hashlib.pbkdf2_hmac('sha256', salted_input, salt, 600_000)
    # Store as base64 for database friendliness
    stored_hash = base64.b64encode(hash_bytes).decode('utf-8')
    stored_salt = base64.b64encode(salt).decode('utf-8')
    return stored_salt, stored_hash

def verify_password(password: str, stored_salt: str, stored_hash: str) -> bool:
    salt = base64.b64decode(stored_salt)
    salted_input = salt + password.encode('utf-8')
    hash_bytes = hashlib.pbkdf2_hmac('sha256', salted_input, salt, 600_000)
    return base64.b64encode(hash_bytes).decode('utf-8') == stored_hash

# Usage
salt, hashed = create_user_password('P@ssw0rd!', 'user_42')
print(f'Salt: {salt}')
print(f'Hash: {hashed}')
print(f'Verify correct: {verify_password("P@ssw0rd!", salt, hashed)}')
print(f'Verify wrong:   {verify_password("wrong", salt, hashed)}')

Why Salting Matters When You Have 10 Million Users

Rainbow tables are precomputed hash chains that let an attacker reverse a hash in seconds — but only if you didn't salt. A single salt for your whole database? That's a shared secret, and once it's leaked, every hash is vulnerable.

Here's the real threat: credential stuffing. Attackers buy password dumps from other breaches. They try those passwords against your login endpoint. Without salting, if user A and user B both use "Summer2024!", you've got a matching hash. That's a signal — the attacker now knows which accounts share passwords, and they'll target the high-value ones first.

Salting also makes dictionary attacks computationally expensive. An attacker must compute a new hash for each salt-password combination. With 10 million users, that's 10 million hash calculations per password guess — not one. That's the difference between a weekend script and a multi-year project.

If you're building anything that stores passwords, assume your database will be dumped. Salt ensures that dump is useless without per-user compute.

// io.thecodeforge — system-design tutorial

import hashlib

# Simulating an unsalted database dump (real passwords)
password_db = {
    'alice': hashlib.sha256(b'P@ssw0rd!').hexdigest(),
    'bob':   hashlib.sha256(b'Secure99#').hexdigest(),
    'eve':   hashlib.sha256(b'P@ssw0rd!').hexdigest(),  # Same as alice!
}

# Attacker spots duplicate hashes
alice_hash = password_db['alice']
eve_hash = password_db['eve']
if alice_hash == eve_hash:
    print('[!] ALERT: Duplicate hash detected — same password across users')
    print(f'    alice hash: {alice_hash[:16]}...')
    print(f'    eve   hash: {eve_hash[:16]}...')
    print('    Attacker deduces: (1) password reuse (2) no salting')
else:
    print('Hashes differ — salting working as intended')

# Output: The attacker doesn't even need to crack the hash;
# the duplicate tells them everything they need.