Password Hashing: Why MD5 and SHA-256 Both Fail

Every leaked database teaches the same lesson within days: accounts protected by MD5 or plain SHA-256 fall first, and the cracked passwords unlock email, banking, and corporate accounts reused elsewhere. The math isn't close. Fast hashes let a single GPU test billions of guesses per second, while purpose-built password hashes hold the same rig to a handful of tries.

The confusion persists because SHA-256 sounds secure. It is secure for checksums and message integrity, where speed is a virtue. Password storage needs the opposite: deliberate slowness, unique salts, and memory hunger that cripples parallel crackers. MD5 adds broken collision resistance on top; unsalted SHA-256 adds rainbow-table vulnerability. Neither belongs near credentials.

The modern answer is settled and boring: bcrypt with a calibrated cost factor, or Argon2id tuned for your hardware, each with per-user salts, plus a pepper for breach containment. Migration doesn't require a password reset for everyone; stacked transparent upgrades move users over as they log in.

This guide shows why fast hashes fail with real numbers, how to configure bcrypt and Argon2id correctly, and the migration path that gets you there without downtime. You'll leave able to defend the choice in review and spot MD5 the moment it appears in a schema.

Why Speed Kills: MD5 and SHA-256 Against GPU Rigs

General hashes optimize for throughput: checksums must fly through gigabytes, so MD5 and SHA-256 finish in nanoseconds with tiny state. Password crackers exploit exactly that. A single commodity GPU tests on the order of 20 billion MD5 guesses per second and over a billion SHA-256, sweeping common password spaces in hours. Eight-character patterns, dictionary words with rules, and previously leaked passwords all fall within a weekend.

Salts don't rescue fast hashes by themselves. A unique salt per user defeats precomputed rainbow tables, forcing per-user guessing, but each guess stays nanoseconds cheap. Attackers simply point the rig at high-value accounts first: admins, then early users, then everyone. The incident above cracked 68 percent of 120,000 rows because cheap guesses compound across the whole table.

Collision resistance is a separate MD5 failure worth naming. MD5 collisions are practical, so MD5 can't vouch for file or certificate integrity either. SHA-256 remains fine for integrity and checksums; its sin is only speed in the password role. Using the right primitive per job is the lesson, not fearing SHA-256 everywhere.

The takeaway for reviews is a one-line rule: any password verifier computable billions of times per second is broken by definition. Password storage must cost real time and memory per guess, which is what the next sections configure.

bcrypt Work Factors: Tuning Slowness You Can Feel

bcrypt's cost factor sets how slow each hash runs, doubling work with every increment. Cost 10 takes roughly tens of milliseconds, cost 12 lands near a few hundred milliseconds on current server hardware. That delay is invisible to a human logging in once and devastating to a rig attempting millions of guesses. The factor is stored with the hash, so verification automatically uses the right cost.

Tune the factor on production-grade hardware, not laptops. Benchmark hashpw across costs 10 through 13, pick the slowest value keeping logins under about 400 milliseconds at peak load, and record the choice with a review date. Revisit annually as hardware improves; bumping the factor is a config change, not a migration.

bcrypt salts automatically: each hash embeds a unique 128-bit salt, so identical passwords produce different strings and rainbow tables die. Its 72-byte password limit deserves a pre-hash for very long passphrases: HMAC with the pepper first, then bcrypt, keeps entropy without truncation surprises.

Deploy with rehash-on-login. Store the cost alongside verification logic that rehashes whenever the stored cost trails the current setting. Every login transparently upgrades one account, and dashboards show the old-cost population draining without a maintenance window.

import bcrypt
import time

COST = 12

def hash_password(password: str) -> str:
    salt = bcrypt.gensalt(rounds=COST)  # unique 128-bit salt embedded
    return bcrypt.hashpw(password.encode('utf-8'), salt).decode()

def check(password: str, stored: str) -> bool:
    return bcrypt.checkpw(password.encode('utf-8'), stored.encode())

def needs_upgrade(stored: str) -> bool:
    # Rehash accounts still on older, faster costs at next login.
    return int(stored.split('$')[2]) < COST

t0 = time.perf_counter()
stored = hash_password('correct horse staple')
print(f'hash took {time.perf_counter() - t0:.2f}s; ok={check("correct horse staple", stored)}')

Argon2id: Memory-Hardness Against GPUs and ASICs

Argon2id is the modern first choice because it taxes memory, not just time. Each guess must hold a large working buffer, typically tens of megabytes, which cripples GPUs and custom chips built for thousands of tiny parallel computations. CPUs handle one login easily; cracking rigs run out of RAM long before they run out of patience.

Three parameters control the defense: memory cost sets the buffer size, time cost sets the passes over it, and parallelism sets the lanes. Sensible starting points on current servers are 64 MB memory, 3 passes, and parallelism matching cores, tuned so verification lands in the same 200 to 400 millisecond band as bcrypt. Raise memory before time when hardware allows, since RAM is the scarcest attacker resource.

Libraries keep this simple. argon2-cffi and language-native bindings generate unique salts automatically, encode parameters with the hash, and expose needs_rehash checks for transparent upgrades. Store the full encoded string; it carries everything verification needs without extra columns.

Choose Argon2id for new systems and bcrypt where FIPS or legacy constraints require it. Both beat any fast hash by orders of magnitude; Argon2id's memory edge is what earns it the default recommendation today.

from argon2 import PasswordHasher
from argon2.exceptions import VerifyMismatchError

# Memory-hard defaults: 64 MiB, 3 passes, parallelism 4.
ph = PasswordHasher(time_cost=3, memory_cost=65536, parallelism=4)

def hash_password(password: str) -> str:
    return ph.hash(password)  # salt + params embedded in output

def check(password: str, stored: str) -> bool:
    try:
        return ph.verify(stored, password)
    except VerifyMismatchError:
        return False

stored = hash_password('correct horse staple')
print('argon2id ok:', check('correct horse staple', stored))
print('upgrade due:', ph.check_needs_rehash(stored) is True)

Salts, Peppers, and KMS: Containing the Inevitable Leak

Salts and peppers solve different halves of the leak. A salt is unique per user, stored with the hash, and stops precomputation: identical passwords hash differently, so attackers guess each account individually. Every modern scheme generates salts automatically, which is why hand-rolled salt columns are now a smell rather than a skill.

A pepper is a secret shared across the app but stored outside the database, applied before hashing. When only the hash table leaks, guesses can't even be tested without the pepper. Hold it in a KMS or HSM-backed secret, version it with identifiers for rotation, and apply it via HMAC rather than raw concatenation to avoid construction pitfalls.

KMS envelope patterns add audit and rotation. The app requests HMAC or decryption at login time, KMS logs each use, and rotation re-wraps without touching every row at once. Version identifiers in the stored record select the right pepper during stacked verification.

Layer honestly: pepper contains database-only breaches but not full-host compromise. It buys the hours needed for resets and rotation after a SQL dump, which is exactly the scenario postmortems keep describing. Pair it with slow hashing rather than treating it as a substitute.

import hmac
import os
from argon2 import PasswordHasher

# In production load PEPPER from KMS/Vault at boot, never from source control.
PEPPER = os.environ.get('PEPPER_V1', 'dev-only-pepper').encode()
ph = PasswordHasher(time_cost=3, memory_cost=65536, parallelism=4)

def hash_password(password: str) -> str:
    mac = hmac.new(PEPPER, password.encode(), 'sha256').hexdigest()
    return 'v1$' + ph.hash(mac)

def check(password: str, stored: str) -> bool:
    version, _, inner = stored.partition('$')
    assert version == 'v1'
    mac = hmac.new(PEPPER, password.encode(), 'sha256').hexdigest()
    try:
        return ph.verify(inner, mac)
    except Exception:
        return False

s = hash_password('correct horse staple')
print('peppered ok:', check('correct horse staple', s))

Migration Without Downtime: Stacked Transparent Upgrades

Migration stalls on fear of flag days, but stacking removes the need. Keep the legacy verifier beside the new one: check Argon2id first, fall back to MD5 or SHA-256 once for old rows, and when the fallback succeeds, hash the just-presented password with the new scheme and store it. Each login upgrades exactly one account with zero user friction.

Order the rollout defensively. Ship stacked verification first with dashboards counting legacy rows, force resets for admins and high-risk accounts immediately, then let natural logins drain the rest. Set a deadline after which remaining legacy accounts must reset, since dormant accounts never log in to upgrade.

Details that bite: constant-time comparison on the legacy path avoids timing leaks, rate limiting survives the transition unchanged, and breach-password screening applies at reset and registration. Test the stack with accounts on each scheme plus wrong-password cases before enabling.

Watch the drain graph weekly. The incident team above cleared active accounts within days and forced the dormant tail at the deadline. Legacy-zero is the milestone that closes the postmortem, not the deploy date. Announce the deadline early so dormant owners expect the reset email.

import hashlib

# Stacked migration pattern: legacy MD5 verified once, then upgraded.
# New hashes in production should be Argon2id; PBKDF2 stands in here
# so this demo runs on the standard library.
legacy_db = {}
new_db = {}

def legacy_hash(password: str) -> str:
    return hashlib.md5(password.encode()).hexdigest()

def new_hash(password: str, salt: bytes) -> str:
    return hashlib.pbkdf2_hmac('sha256', password.encode(), salt, 210000).hex()

def login(user: str, password: str) -> str:
    if user in new_db:
        salt_hex, stored = new_db[user]
        return 'ok' if new_hash(password, bytes.fromhex(salt_hex)) == stored else 'deny'
    if user in legacy_db and legacy_db[user] == legacy_hash(password):
        import os
        salt = os.urandom(16)
        new_db[user] = (salt.hex(), new_hash(password, salt))
        del legacy_db[user]
        return 'ok-upgraded'
    return 'deny'

legacy_db['ana'] = legacy_hash('s3cret!')
print(login('ana', 's3cret!'))
print(login('ana', 's3cret!'))

Policy Around Hashing: Length, Screening, and Stuffing Defense

Hashing is the last line; password policy is the first. Require lengths users can meet with phrases rather than tortured complexity rules, following current NIST guidance toward minimum length and breach screening. Check new passwords against known-compromised lists at registration and reset, rejecting the 81,000-style entries crackers already own.

Assume reuse and defend the login endpoint. Rate limit by account and IP, alert on spray patterns with many accounts and few passwords, and offer phishing-resistant MFA for high-value roles. The incident's 4,300 stuffing successes came from reused passwords, not from breaking Argon2id; endpoint defenses are what stop the replay.

Communicate honestly after leaks. Tell users what was stored, what changed, and what to do about reuse elsewhere. Forced resets plus session revocation contain the damage; vague reassurance extends it.

Review the whole stack yearly: cost factors against current hardware, pepper rotation, screening list freshness, and legacy-hash counts. Password security is a maintained posture across hashing, policy, and monitoring, not a single algorithm choice. Fund the yearly review like any other security control: scheduled, owned, and evidenced with scan outputs.