Re: [VOTE] Increasing the default BCrypt cost

Hi On 9/25/23 21:43, Levi Morrison via internals wrote:

I did a tiny bit of my own research, and could not find any recommendations more specific than "10 or more" as the cost factor. Typically, the advice is "use a more modern system like argon2id".

Please see this email of mine regarding Argon2: https://news-web.php.net/php.internals/120996 Other than that, the recommendation for BCrypt's cost factor (and basically also Argon's tunables) is "as high as feasible for your use case". See also this post on Fediverse (it's also referenced in the initial email of the voting thread): https://phpc.social/@tychotithonus@infosec.exchange/111025157601179075

However, I did notice some sites mention that systems ought to check for a maximum length of 72 bytes when using bcrypt: https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#input-limits As far as I can tell, PHP does not do this check. I am not sure if the implementation(s) used suffer(s) from the limitation that is the source of this recommendation. Perhaps someone has time to investigate this? Anyway, it's "future work."

BCrypt-as-specified has a limit of at most 72 bytes, none of which may be NUL. Additional characters will simply be ignored. Think of it like the password would be passed through substr($password, 0, 72). The implementation used is crypt_blowfish by Openwall [1]. The limit in the source code is given by this loop: https://github.com/php/php-src/blob/2e8cdd8eecac5d34619bbd03916d0b7bcc2cc023/ext/standard/crypt_blowfish.c#L580-L582 (BF_N (16) + 2) * 4 is 72 The behavior for longer passwords is well-defined, so I'd say that PHP doesn't need any additional check. The only thing that could be done differently is throwing an exception and this is likely not a good idea for such a generic function as 'password_hash'.

I have voted for 11, but will not be hurt in any way if 12 wins.

Best regards Tim Düsterhus [1] https://github.com/openwall/crypt_blowfish