Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121140
Message-ID: <05ef9741-7a5d-cfc7-1e3d-42071fac232a@bastelstu.be>
Date: Mon, 25 Sep 2023 19:07:16 +0200
MIME-Version: 1.0
Content-Language: en-US
To: Craig Francis <craig@craigfrancis.co.uk>,
 Nicolas Grekas <nicolas.grekas+php@gmail.com>
Cc: PHP internals <internals@lists.php.net>
References: <a9b0d24f-fe59-75af-4b1e-dcd8067482b0@bastelstu.be>
 <CAOWwgp=cJWtF8GS6h9Aq42bwJXTwbkG1L1LpcS7HLqK0hrj5rQ@mail.gmail.com>
 <44945ACB-066E-4805-8EF2-26796BA01671@craigfrancis.co.uk>
In-Reply-To: <44945ACB-066E-4805-8EF2-26796BA01671@craigfrancis.co.uk>
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/22/23 10:46, Craig Francis wrote:
> On 22 Sep 2023, at 08:04, Nicolas Grekas <nicolas.grekas+php@gmail.com> wrote:
>> For the record, I voted for 11 because I think it's nicer to end users (I guess many don't know they could have a potential DoS vector via password submissions), and also because it's going to be easy to raise again in 8.5/9.0.
> 
> [...]
> I can't vote, but I would urge people to be careful with this.

I've now did the maths and you really need rate limiting no matter if 
you use costs 10, 11 or 12, so I believe the DoS argument is a little moot.

Taking the Xeon(R) E-2246G CPU as the fastest CPU within the RFC itself 
(only beaten by Alexandru's Xeon Gold 5416S):

Verifying a single cost-11 hash keeps a single core busy for ~80ms. This 
allows for calculating 12.7 cost-11 hashes per core and second. The CPU 
is a 6C/12T CPU. SMT likely does not provide a performance benefit, 
because the cores will generally be busy all the time, but let's just 
assume SMT scales linearly for sake of the argument. Rounding up 
generously that means this CPU can calculate ~155 cost-11 hashes per second.

A single computer on a slow Internet connection is easily capable of 
sustaining 155 HTTP requests per second. For reference a single HTTP/2 
TCP connection commonly allows for 100 concurrent streams as per 
https://stackoverflow.com/a/36847527/782822.

The current costs of 10 would allow for roughly twice the amount of 
hashes per second, resulting in the CPU being saturated at just 300 
requests per second, still easily emitted with a single low-bandwidth 
computer.

For the Xeon Gold 5416S which needs 0.1s / cost-12 hash (i.e. 50ms per 
cost-11 hash) you can do 20 cost-11 hashes per core and second. This CPU 
has 16C/32T, resulting in less than 640 hashes per second if you assume 
SMT scales linearly.

> While a high cost might make you *feel* good, the DoS problem is real, especially on older hardware - 10 is still fine today, 11 is a fair improvement against brute force guessing, 12 is just burning CPU cycles today, simply because the difference does not address the problem of commonly used passwords (like 123456, password1, monkey, etc).

The attacker does not know which users use less secure passwords and 
thus will spend effort for "secure" and "insecure" passwords alike. 
Doubling the costs will mean that each password takes twice as long to 
crack on average, making cracking twice as expensive. For less secure 
passwords that can make the difference between "being cracked" and "not 
being cracked" if the attacker is willing to spend a given amount of CPU 
time per password.

> Also, if you want to increase the cost yourself, on a system which blocks too many password attempts, you can do that easily - this is about the default, for people who are not customising it for their (shared/old) hardware.
> 

I believe it would be correct to assume that higher-traffic websites 
which are at a risk of denial of service (e.g. by folks that envy their 
success) would generally be sufficiently knowledgeable to make an 
explicit choice for their workload. The less experienced folks that will 
rely on the defaults are probably also the folks who are most likely to 
be breached and thus higher costs provide a real value-add against 
hashes being cracked.

Best regards
Tim Düsterhus