Hi
On 9/22/23 10:46, Craig Francis wrote:
On 22 Sep 2023, at 08:04, Nicolas Grekas <nicolas.grekas+...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
