Re: [VOTE] Increasing the default BCrypt cost

On 25 Sep 2023, at 18:07, Tim Düsterhus <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). > > 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=OQD3qDYMyYQ&t=381s