Re: [RFC] Add PASSWORD_BCRYPT_SHA256 to password_hash
| From: | Rowan Tommins [IMSoP] | Date: | Fri, 09 Oct 2026 11:02:03 +0000 |
| Subject: | Re: [RFC] Add PASSWORD_BCRYPT_SHA256 to password_hash | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-132850@lists.php.net to get a copy of this message | ||
Hi Mirco,
On 8 October 2026 19:04:33 BST, Mirco Babin <mirco.babin@gmail.com> wrote:
>OWASP states, see
>https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#pre-hashing-passwords-with-bcrypt
I looked up the attack discussed there, "password shucking" or "hash shucking",
and as I understand it, it requires *the same inner hash* to be used somewhere else, that the
attacker can match *to that user*.
In the proposed algorithm, that means that somewhere else has passwords stored as HMAC-SHA256(salt,
password) and has the same password, *and the same salt*, for the same user. Unless I'm missing
something, that's staggeringly unlikely.
To put it another way, the salt in the proposal's HMAC is essentially doing the same thing as
the pepper in the OWASP suggestion - making it sufficiently unlikely that an attacker can find the
exact inner hash they need somewhere else.
I also see, in the section above that, that OWASP endorses Sjoerd's original proposal:
> ... so you should enforce a maximum password length of 72 bytes
Even an expert opinion is just an opinion, of course, but it does mean we're going in circles a
bit.
Regards,
Rowan Tommins
[IMSoP]