Hashing Passwords Correctly

Two announcements, same week. Company A shipped md5($password) and, when the dump surfaced, thousands of accounts fell within hours — every hash is a fixed length, GPUs test billions of candidates per second, and the most common passwords are public lists. Company B's dump surfaced and the cracking bench produced almost nothing. The difference is not a cleverer algorithm; it is three decisions baked into password_hash():

$hash = password_hash($password, PASSWORD_DEFAULT);
// $2y$10$K9u1O0jX1kQm0R7xQe2uLu5y7Wc8v1Zq3n9pQ2sT4uV6wX8yZ0aBc — algorithm, cost, salt, digest

Read the string: $2y$ is bcrypt, $10$ is the cost, and the next 22 characters are a salt that was generated for this one password. What each decision buys:

Salt kills precomputation. Rainbow tables map hash → password once for millions of inputs; a per-password salt changes the input every time, so one rainbow table is worth exactly one account. password_hash() generates 16 random bytes itself and embeds them in the output — you never manage salts, which means you never reuse them, which is the classic hand-rolled failure (md5($salt . $password) with $salt from a config file).

Cost kills speed. Bcrypt runs the Blowfish key schedule 2^cost times — cost 10 is 1024 rounds, roughly 60–150 ms on a 2020s server CPU, and each +1 doubles that. Attackers buy GPUs and FPGAs precisely because fast hashes amortize; at ~100 ms per guess, an offline attacker's throughput collapses from billions per second to single-digit guesses per second per core. That asymmetry — your server pays it once per login, the attacker pays it per candidate, forever — is the entire economics of password storage.

Two API points interviews ask directly. PASSWORD_DEFAULT is not "md5" or a constant you pick — it is the strongest algorithm PHP currently ships as the default (bcrypt, $2y$, today), and it may change in a future release, so your column must be sized for a hash you have not met yet: VARCHAR(255) fits bcrypt's 60 characters and Argon2id's ~96 with room to spare. PASSWORD_BCRYPT pins bcrypt explicitly and accepts tuning:

$hash = password_hash($password, PASSWORD_BCRYPT, ['cost' => 12]);            // pinned + tuned
$hash = password_hash($password, PASSWORD_ARGON2ID, [                         // PHP 7.3+, libsodium
    'memory_cost' => 65536,   // 64 MB per hash — memory-hard, GPU-hostile
    'time_cost'   => 4,
    'threads'     => 1,
]);

What you must never substitute: hash('sha256', $password) — fast, unsalted by itself, and "salt it yourself" only rebuilds a fast hash with extra steps; encrypt()/decrypt() style reversible storage, which turns one SQL read into a plaintext breach; and any home-made construction — hash_hmac with a pepper from the environment is a defensible addition (it survives a database-only theft), but the primary must remain a slow, salted password KDF. OWASP's password-storage guidance says the same thing: bcrypt, Argon2id, or PBKDF2 with a workload an attacker must pay per guess.

Next: what happens at login, where password_verify() decides in constant time and password_needs_rehash() quietly upgrades yesterday's cost to today's.

Verification is where the stored format proves itself:

$stmt = $pdo->prepare('SELECT id, password_hash FROM users WHERE email = :email');
$stmt->execute([':email' => $email]);
$user = $stmt->fetch();

if (!$user || !password_verify($password, $user['password_hash'])) {
    // one generic message for both branches — see the note below
    http_response_code(401);
    exit('Invalid email or password');
}

if (password_needs_rehash($user['password_hash'], PASSWORD_BCRYPT, ['cost' => 12])) {
    $up = $pdo->prepare('UPDATE users SET password_hash = :h WHERE id = :id');
    $up->execute([':h' => password_hash($password, PASSWORD_BCRYPT, ['cost' => 12]),
                  ':id' => $user['id']]);
}
session_regenerate_id(true);          // new session id the moment privilege changes

Follow what password_verify() does with the stored string: it parses algorithm, cost, and salt out of $2y$10$…, recomputes the digest from your submitted password with those parameters, and compares — it never reverses anything, never returns or reconstructs the plaintext, and never decodes it. A malformed or truncated hash makes it return false rather than throwing, so a corrupted column fails closed as "wrong password" instead of taking the endpoint down. The bcrypt computation dominates the runtime (~100 ms either way), so timing tells an attacker nothing useful about the password itself.

Three login-flow details that interviews probe:

• One message for both branches. "Email not found" versus "Wrong password" is user enumeration: an attacker assembles a valid-address list from response differences before touching a single hash. Combine the branches as above, and consider a deliberate, identical delay on the failure path.
• session_regenerate_id(true) right after success. The session fixation attack plants a session id before login and reads it after; regenerating on the privilege change makes the pre-login id worthless, while true deletes the old session file so the planted id cannot be reused either. Keep $_SESSION (your CSRF token survives) — only the id rotates.
• Upgrade on login, never re-hash offline. password_needs_rehash($stored, PASSWORD_BCRYPT, ['cost' => 12]) answers "does this stored value match the algorithm and options I use now?" — different algorithm, lower cost, changed Argon2 parameters all return true. Because the plaintext is available at exactly one moment — the successful login — that is the only moment a rehash can ever happen. Raising cost from 10 to 12 then migrates the whole user base one login at a time, with zero notices sent.

Migrating a legacy md5/sha1 column without forcing a reset:

function legacy_ok(string $password, string $stored): bool
{
    return hash_equals(hash('md5', $password), $stored)
        || hash_equals(hash('sha1', $password), $stored);
}

$stored = $user['password_hash'];
$ok = password_get_info($stored)['algoName'] !== 'unknown'
    ? password_verify($password, $stored)
    : legacy_ok($password, $stored);

if ($ok) {
    $new = password_hash($password, PASSWORD_DEFAULT);          // bcrypt from now on
    $pdo->prepare('UPDATE users SET password_hash = :h WHERE id = :id')->execute([':h' => $new, ':id' => $user['id']]);
}

password_get_info() reports algoName: unknown for anything it does not recognize — that single check tells native-format hashes from hex digests, so one login path serves both populations. Two caveats: keep the legacy branch behind a deadline (every login weakens the argument for keeping it, and md5 stays crackable for dormant accounts — a forced reset for stragglers is the honest end state), and hash comparisons use hash_equals() even here, so the legacy path does not introduce a timing oracle of its own.

What never belongs anywhere near this flow: logging the submitted password, echoing it in an error, putting it in a URL or redirect, or storing it "just for now" in a session or cache. Validation of what arrives is the job of the previous topic, Validating and Sanitizing Input — by the time a password reaches this code, it is only ever handled by these functions.

A correct hash with a careless login around it still loses accounts. Four mistakes account for most of the damage.

1. Bcrypt truncates at 72 bytes — not characters. password_hash() passes the password through bcrypt's 72-byte limit, so every character past byte 72 is ignored:

$long1 = str_repeat('A', 70) . 'SECRET-ONE';
$long2 = str_repeat('A', 70) . 'SECRET-TWO';
password_verify($long1, password_hash($long2, PASSWORD_DEFAULT));   // true — same first 72 bytes

For 3-byte UTF-8 text (CJK, accented characters) 72 bytes is only 24 characters, so a passphrase policy that promises "unlimited length" quietly isn't. Pick a policy and enforce it explicitly — reject over 72 bytes (strlen($password) > 72) with a clear message, or pre-hash long inputs (password_hash(hash('sha256', $password, true), PASSWORD_BCRYPT), applied consistently at hash and verify time). What you must not do is truncate silently, because users then believe their tail characters count.

2. Cost is a measurement, not a superstition. Benchmark on hardware that looks like production:

foreach ([10, 11, 12, 13] as $cost) {
    $t = microtime(true);
    password_hash('correct-horse-battery-staple', PASSWORD_BCRYPT, ['cost' => $cost]);
    printf("cost %2d → %5.0f ms\n", $cost, (microtime(true) - $t) * 1000);
}

Aim for ~100–250 ms per hash: fast enough that login feels instant, slow enough that offline guessing crawls. Two forces pull in opposite directions — an attacker can trigger unlimited logins and burn your CPU, so the cost cannot climb without bound (pair it with per-account and per-IP rate limits), and hardware improves, so password_needs_rehash() at the new cost is how you keep up. PHP's default is cost 10; raising it is a one-line change that migrates users at their next login.

3. Password policy theater beats no policy, badly. "Must contain an uppercase, a digit, and a symbol" reliably produces Summer2026! — a pattern on every attacker's list — while blocking correct horse battery staple. What actually works: a length floor (12+ characters), a check against known-breached passwords (the k-anonymity range API sends only a hash prefix, never the password), per-account rate limiting with progressive lockout, and a second factor for high-value accounts. Do not rotate passwords on a schedule without cause — every forced rotation trains users toward Password1! variants.

4. Skipping the session step. The hash protects storage; the session protects the live login. Rotating the session id at login (shown in the previous chapter) closes session fixation, and the cookie flags — HttpOnly, Secure, SameSite — are covered in Security Headers and Cookie Flags.

Also on the "looks safe, isn't" list: double-hashing (md5(md5($p))) compounds speed, not cost; salting twice adds nothing because password_hash() already salts; comparing with == reopens type juggling (0e… digests are numeric strings that compare equal — the reason hash_equals() exists); and password_hash() throws a ValueError on an unknown algorithm in PHP 8, so a typo'd constant is a 500 rather than a silent plaintext write.

The summary an interviewer will accept in one breath: password_hash(PASSWORD_DEFAULT) stores a salted, slow KDF; password_verify() checks without reversing; password_needs_rehash() upgrades the cost on the next login — and nothing else ever sees the plaintext.