On Thu, 29 Oct 2026 at 20:07, Andrey Andreev <[email protected]> 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
