Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121143
Message-ID: <749cf61e-b9b4-dc8b-facb-a19f76df4333@bastelstu.be>
Date: Mon, 25 Sep 2023 21:58:00 +0200
MIME-Version: 1.0
Content-Language: en-US
To: Levi Morrison <levi.morrison@datadoghq.com>
Cc: PHP internals <internals@lists.php.net>
References: <a9b0d24f-fe59-75af-4b1e-dcd8067482b0@bastelstu.be>
 <CAAKU0u=owpz5OEPUzKqPWQQEam+9gYqBCCUqnxUBQCvZU00QVw@mail.gmail.com>
In-Reply-To: <CAAKU0u=owpz5OEPUzKqPWQQEam+9gYqBCCUqnxUBQCvZU00QVw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [VOTE] Increasing the default BCrypt cost
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=c3=bcsterhus?=)

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