password_hash(): Rejecting Bcrypt Passwords Over 72 Bytes

Bcrypt only reads the first 72 bytes of a password. When you pass password_hash() something longer with PASSWORD_BCRYPT, PHP hashes the first 72 bytes and quietly ignores the rest. Sjoerd Langkemper's RFC turns that silence into a deprecation notice in PHP 8.7 and a ValueError in PHP 8.8.

Normal passwords rarely get near 72 bytes, so the RFC is aimed at code that builds a longer string before hashing it, like prepending a pepper, a nonce or another hash. The RFC points to CVE-2025-68402 in FreshRSS, where a 64-character nonce was prepended to a value before hashing. The first 72 bytes held only the nonce and the bcrypt header, so any password was accepted.

What changes#

Here is the RFC's example:

// Valid passwords (<= 72 bytes) work normally across all versions:
$hash = password_hash('correct-horse-battery-staple', PASSWORD_BCRYPT);

$longPassword = str_repeat('a', 80);

// PHP 8.7: E_DEPRECATED
$hash = password_hash($longPassword, PASSWORD_BCRYPT);

// PHP 8.8: ValueError
try {
    $hash = password_hash($longPassword, PASSWORD_BCRYPT);
} catch (ValueError $e) {
    // password_hash(): Password length cannot exceed 72 bytes when using PASSWORD_BCRYPT
}

The check covers PASSWORD_DEFAULT too, as long as it resolves to bcrypt. The RFC picks ValueError over a regular exception because it treats a password over 72 bytes as a mistake in how the code calls the function, not as user input the app should catch and recover from.

password_verify() doesn't change. Throwing there would lock out anyone who already has a hash made from a longer input, so existing hashes keep verifying the way they do today, and only new hashes get the check.

What it means for existing code#

If your app hashes user passwords as they are, nothing changes. If it adds a pepper, a nonce or a long identifier before calling password_hash(), you'll see deprecation notices on 8.7 and errors on 8.8. The RFC suggests three ways out: check the length first, pre-hash the input (for example with SHA-256 or SHA-512) before passing it to bcrypt, or move to Argon2id with PASSWORD_ARGON2ID, which has no 72-byte limit.

Frameworks and auth libraries that accept passwords of any length or prepend secrets will need one of those too.

Where it stands#

This is still a draft. Sjoerd Langkemper opened it on September 27, 2026, and it hasn't been announced on the internals list yet. There's an implementation up for review in php-src PR #23076. A vote would need a two-thirds majority.