Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121144
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\))
In-Reply-To: <05ef9741-7a5d-cfc7-1e3d-42071fac232a@bastelstu.be>
Date: Mon, 25 Sep 2023 21:45:36 +0100
Cc: Nicolas Grekas <nicolas.grekas+php@gmail.com>,
 PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <27DD144B-31CC-44D1-B20A-9C6254F8D853@craigfrancis.co.uk>
References: <a9b0d24f-fe59-75af-4b1e-dcd8067482b0@bastelstu.be>
 <CAOWwgp=cJWtF8GS6h9Aq42bwJXTwbkG1L1LpcS7HLqK0hrj5rQ@mail.gmail.com>
 <44945ACB-066E-4805-8EF2-26796BA01671@craigfrancis.co.uk>
 <05ef9741-7a5d-cfc7-1e3d-42071fac232a@bastelstu.be>
To: =?utf-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
Subject: Re: [PHP-DEV] [VOTE] Increasing the default BCrypt cost
From: craig@craigfrancis.co.uk (Craig Francis)

On 25 Sep 2023, at 18:07, Tim D=C3=BCsterhus <tim@bastelstu.be> wrote:
> 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.


Yes, someone being malicious could easily generate enough requests to =
create an Denial of Service Attack, but I was referring to normal users =
logging in, on a small hosting service.

Think of a little web-shop that has just sent out an email to ~30,000 =
customers, and initially they get a gentle ~20 customers logins at a =
time... with a cost of 10, that causes the HTML for other all other =
pages to go from 0.09 seconds to ~1.1 seconds, not good, but manageable; =
cost of 11 takes that to ~2.1 seconds; cost of 12 goes to ~4.2 seconds.

(I got those numbers with a simple `ab -n 200 -c 20` to call =
password_hash, and `while true; do curl -o /dev/null -s -w =
'%{time_total}\n'` to request a basic page while this is running to get =
some rough averages).




>> 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).
>=20
> 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.


Yep, and we are defining a baseline, a default that is good enough for =
everyone; this is why I'd consider what is being achieved, think of =
normal customers, choosing passwords that can be found on the 14.3 =
million record RockYou list, to test that at "640 hashes per second", =
would be 6.2 hours per hash, so the 11 vs 12 cost for these people won't =
really make much of a difference to them.

Craig




For those who want a bit of background, while this 3 years old video =
covers a different subject, @chick3nman (of hashcat fame) notes the =
use/value of bcrypt:

https://www.youtube.com/watch?v=3DOQD3qDYMyYQ&t=3D381s