Re: [VOTE] Increasing the default BCrypt cost
| From: | Tim Düsterhus | Date: | Mon, 25 Sep 2023 16:40:56 +0000 |
| Subject: | Re: [VOTE] Increasing the default BCrypt cost | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-121139@lists.php.net to get a copy of this message | ||
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