Re: [RFC][Discussion] Add PASSWORD_BCRYPT_WRAP

On Thu, 29 Oct 2026 at 20:07, Andrey Andreev <narf@devilix.net> wrote: > > Hi all, > > I'd like to open the discussion on a new password hashing algorithm that I've been > working on, named bcrypt-wrap. > > RFC link: https://wiki.php.net/rfc/password_bcrypt_wrap > Pull request: https://github.com/php/php-src/pull/25040 (just > pushed it, CI still running) > > P.S. Thanks to Sjoerd for honoring my request to delay his bcrypt-sha256 proposal while I > finished this. > > Cheers, > Andrey. Hi Andrey, I'm rather against it. Your proposed implementation decreases security of bcrypt implementation for small and dubious gains. The input space is decreased from 2^576 to 2^432, which is a magnitude of 2^144. Sure, these are astronomical values, but it's a significant decrease nonetheless. Additionally, your implementation suffers from hash shucking. OWASP explicitly warns about doing it the way you are doing it: > Just using pure SHA-512, ( i.e. bcrypt(base64(sha512($password))), $salt, $cost)) is a > dangerous practice and is as secure as just using pure SHA-512. https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet..html You mention HMAC, but it's a bit vague and looking at the implementation, I believe you use the public salt as a secret key. This may obfuscate the hash, but as I understand it, it does not make pre-hashing safe. In fact the blog which I assume you have looked at before (https://soatok.blog/2024/11/27/beyond-bcrypt/) describes the problems in detail: > You can avoid hash shucking by using HMAC with a static key–either universal for all > deployments of your software, or unique per application.. > >It doesn’t really matter which you choose; all you really need from it is domain separation >from naked hashes. So what do we gain instead? Your RFC does not clearly state the benefits we gain at the cost of reduced security. Regards, Kamil Tekiela