[ss248]

You're right. I don't know why it's still not a common knowledge that nobody bruteforces the login pages in this day and age. But I guess too many people, who have products to sell, benefit from the status quo, so things are not going to change.

[hombre_fatal]

No, login pages are definitely "still" brute forced. Why wouldn't they be? It's easier than ever.

[ss248]

>Why wouldn't they be?

Because it's trivial to implement decent ratelimiter which stops attackers, but still allows normal users to login.

[hombre_fatal]

That you must mitigate the attack is a direct point in my favor and a contradiction to yours: "nobody bruteforces the login pages in this day and age".

It's also not a trivial issue. It's cheaper and cheaper to attack a website with unlimited IP addresses. Which dimension are you going to rate-limit?

[ss248]

What do you mean by "which dimension"? Login attempts per second. How you do it? Depends, but basic answer is captcha. How do you make sure normal user are not affected? You monitor the login attempts and use the metadata, like ip address of last successful login and valid/expired cookies, to assign the "level of trust" on that particular attempt. The lower the "level of trust" the longer it should take. If you have evidence to suspect that account is under attack (like you see multiple low level of trust attempts with random ips) you limit the rate even more, with something like "no more than 10 low trust attempts per hour". If you allow to bruteforce thousand-entries password dictionaries in the reasonable time frame, it doesn't mean the "bruteforce problem" is not solved, it just means that your system is defective.

There is no lock that cannot be lockpicked. The only difference between a good lock and a bad lock is amount of time it takes to lockpick it.

[hombre_fatal]

You're starting to build a hand-wavy levitation machine though ("monitoring metadata", "level of trust"), and confirming that it's not so trivial, which is the assertion that started this thread.

And captcha only makes brute-force somewhat more expensive. You likely have to use a 3rd party captcha service (like Recaptcha) which incurs network volume amplification since you need a req/res to Google just to render GET /login. It also shows how hard of a problem captcha is that you can't just roll it yourself.

You're still not addressing the problem since IP addresses are so cheap. I only need 1,000 IP addresses to try the top 1,000 passwords in parallel no matter what your rate-limit scheme is unless you plan on letting me lock the authentic user out of their own account.

You've wandered from your original claim that bruteforce doesn't even happen these days, and I'm certainly not saying we are helpless against it. In the end, I'd simply suggest that this problem is harder than you originally gave it credit for, and maybe that's something we can agree on.

[ss248]

I didn't change my argument. "Just bruteforce the login page" is not a go-to method of the competent attacker. Why? Because it's trivial to stop it.

You want simple concrete example of how to stop all that "unlimited amount of ip addresses with captcha solver service" stuff? No more than 20 attempts per day with ip different from the ip of the last successful login. Here it is, you just solved the "bruteforce problem". That's all you have to do. Other things are just quality of life improvements.

[nsgi]

Just because it's trivial doesn't mean all websites are doing it.

[ss248]

Some sites store passwords as plain text. And?

But if care about security, you might as well solve the problem properly instead of wasting your time implementing "your password must have a capital letter and a number" snake-oil features which only annoy your users.