Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121139
Message-ID: <7ee8e02d-8160-6093-0b89-e8712f170600@bastelstu.be>
Date: Mon, 25 Sep 2023 18:40:56 +0200
MIME-Version: 1.0
Content-Language: en-US
To: Theodore Brown <theodorejb@outlook.com>,
 PHP internals <internals@lists.php.net>
References: <a9b0d24f-fe59-75af-4b1e-dcd8067482b0@bastelstu.be>
 <BN7PR05MB4033859F6C9BF0BBB64EFE36DEFCA@BN7PR05MB4033.namprd05.prod.outlook.com>
In-Reply-To: <BN7PR05MB4033859F6C9BF0BBB64EFE36DEFCA@BN7PR05MB4033.namprd05.prod.outlook.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 06:20, Theodore Brown wrote:
> Thanks for your work on this. I think bumping the default BCrypt cost from 10 to 11 is reasonable, as this typically adds less than 100 milliseconds additional latency, which shouldn't be too noticeable for users logging in.
> 
> However, I am concerned about changing the default directly from 10 to 12. Per the benchmarks in the RFC, even on recent hardware like the Apple M1 Pro this adds 179 ms additional time to verify a password (compared to 60 ms for the change to 11). This would be a noticeable slowdown for user logins.
> 
> It gets even worse on older hardware, with the example of the 2011 Core i5 adding 247 milliseconds additional time at a cost of 12, vs. 81 ms additional time using a cost of 11.

Logging in should generally be a rare thing for a given user, making a 
longer delay more acceptable. All the services I interact with, except 
for my bank, do not ask for a password more than twice per day with the 
majority allowing for indefinite session lengths.

As per 
https://www.nngroup.com/articles/response-times-3-important-limits/, any 
delay above 100ms is perceptible, but as long as it's below 1000ms, it's 
okay without taking any special measures.

As given in the RFC, costs of 12 stay well below 500ms for all tested 
CPUs. The ARM CPUs tested by Remi are slower than the CPUs I tested, but 
even those are below 430ms.

 From my personal experience as a developer of a software that uses 12 
since 2021, costs of 12 do not really feel slow even when logging in 
multiple times in a short period to test the login process.

> It will be easy to bump the default cost again in the future, so I think a more gradual increase will be safer to avoid an obvious degradation to user login time.

I'm concerned about this actually happening. Increasing the default from 
10 is *long* overdue and is only happening, because I accidentally 
stumbled over this issue. As far as I can tell there is no procedure to 
perform this kind of periodic reevaluation of defaults.

Best regards
Tim Düsterhus