Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121009
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
In-Reply-To: <e6d0f349-436d-8545-4146-e1293c901d65@bastelstu.be>
Date: Thu, 7 Sep 2023 22:37:39 +0100
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <6D9D6C50-EF11-48B6-AA3E-311A34EE8B41@craigfrancis.co.uk>
References: <e6d0f349-436d-8545-4146-e1293c901d65@bastelstu.be>
To: =?utf-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
Subject: Re: [PHP-DEV] RFC: Increasing the default BCrypt cost
From: craig@craigfrancis.co.uk (Craig Francis)

On 7 Sep 2023, at 18:26, Tim D=C3=BCsterhus <tim@bastelstu.be> wrote:
> in response to the recent "PASSWORD_DEFAULT value" thread [1], I've =
created an RFC to discuss an increase of the default BCrypt costs for =
`password_hash()` from the current value of 10.
>=20
> https://wiki.php.net/rfc/bcrypt_cost_2023


Thanks Tim,

Just quickly running this on two AWS EC2 servers, to give rough figures =
for a VM (note usual issues like noisy neighbours, turbo-boost, thermal =
throttling, etc).

t2.nano

Cost 8: 2.083060 total (0.020831 per hash)
Cost 9: 4.115596 total (0.041156 per hash)
Cost 10: 8.238419 total (0.082384 per hash)
Cost 11: 16.334089 total (0.163341 per hash)
Cost 12: 32.693785 total (0.326938 per hash)
Cost 13: 65.587982 total (0.655880 per hash)
Cost 14: 131.358058 total (1.313581 per hash)

t2.small

Cost 8: 2.062625 total (0.020626 per hash)
Cost 9: 4.142067 total (0.041421 per hash)
Cost 10: 8.231646 total (0.082316 per hash)
Cost 11: 16.851889 total (0.168519 per hash)
Cost 12: 32.814440 total (0.328144 per hash)
Cost 13: 69.409889 total (0.694099 per hash)
Cost 14: 133.682196 total (1.336822 per hash)

Both nano and small only have 1 vCPU, have 0.5 vs 1 GiB RAM, and a =
different number of CPU Credits/hr.

We recently discussed hashing and costs at one of our OWASP meetings, we =
came to conclusion that the default of 10 for bcrypt probably should be =
increased, but only to 11 for typical websites. The main concern was =
about making denial-of-service attacks easier (think of a normal website =
developer, who won't limit the number of login attempts).

It's also worth keeping in mind the difference between online vs offline =
attacks, what it's being used for, human behaviour when it comes to =
choosing bad passwords ("123456" and "Password1!" will still be guessed =
very quickly), etc.

Craig=