Reject bcrypt passwords longer than 72 bytes proposal

Inactive; not accepted. The status signals conflict. The official RFC index, collected at 10:01 UTC on 5 October, now lists this RFC as inactive. On 4 October it listed it as under discussion, and before that as a draft. The RFC page itself still says Draft, version 0.1, and its changelog has only its 2026-09-27 entry. Its discussion-thread field links the internals thread (news-web.php.net/php.internals/132689). On 5 October the author wrote that the proposal had drawn "much criticism because of its backwards incompatibility" and that they did not think it "is worth pursuing further at the moment". They now propose the opt-in PASSWORD_BCRYPT_SHA256 algorithm instead. The page does not say the RFC is withdrawn. No vote was opened.

What is proposed

When password_hash() uses PASSWORD_BCRYPT (including PASSWORD_DEFAULT when it resolves to bcrypt) and the password exceeds 72 bytes:

• PHP 8.7 would emit E_DEPRECATED;
• PHP 8.8 would throw ValueError.

password_verify() is deliberately left unchanged so that existing hashes made from longer inputs still verify. The RFC proposes a single 2/3-majority vote. Voting has not started, and the page's voting-thread and implementation fields read "tbd". Its references section names php-src pull request #23076 ("Bcrypt 72 byte password handling"). The page's empty vote widget shows 0/0/0 and "This poll has been closed"; that is the template's default rendering, not a ballot.

Discussion so far

The motivation is authentication bypasses caused by silent truncation when applications prepend nonces, peppers or other hashes to the password (the RFC cites CVE-2025-68402 in FreshRSS). Early replies on the list are critical: respondents argue that input length is the application's responsibility and that a runtime error would break users who choose long passphrases. The outcome is open.

Later in the thread, Derick Rethans said he would vote against it because of the backward-compatibility break. This is a stated intention; no vote has been opened. As an alternative, Tim Düsterhus suggested adopting passlib's bcrypt-sha256 construction, a defined pre-hashing scheme with its own output format. He also argued that passing a raw binary pre-hash to bcrypt is fragile because the digest can contain NUL bytes. The RFC author has opened a draft php-src PR, #24073 "bcrypt_sha256", on 2026-10-02. As of 4 October this RFC page (still version 0.1) does not mention this alternative, and nothing in it is accepted. At 11:27 UTC on 4 October the same author created a separate draft RFC, PASSWORD_BCRYPT_SHA256, which proposes the alternative as a new opt-in algorithm. It describes this RFC as a "previous attempt" but does not say it is withdrawn. That RFC moved to discussion on 5 October, when the official index moved this one to inactive. The page has a Discussion section that summarizes the opposition arguments (backward compatibility, the limit being in bytes, which hits multi-byte scripts, sufficient entropy below 72 bytes, rehash-on-login exposure) and the support arguments (harm from silent truncation, NIST guidance against truncation, better API design). It lists no open issues.

Current behavior

Nothing has changed in released PHP. See bcrypt length limits for today's truncation behavior and mitigations.