Hacker News Reader

> For online attacks, an attacker can't even try the top 1000 passwords on for an account in any major website in reasonable time without triggering the alarm, as they all(?) have rate limiting (usually in the form of account lockdown after single-digit failed attempts).

This is empirically a practical attack: attackers successfully executed a common password brute force attack against GitHub in late 2013 by using a botnet with 40,000 distinct remote addresses:

https://github.blog/2013-11-20-weak-passwords-brute-forced/

Our solution for a bitcoin casino was to generate passwords for users. But you can imagine how few sites can get away with such a thing. Our create-password input was a disabled textfield with a reroll button.

Before that, attackers would just wait for new usernames to appear on the scoreboard/chat and check them against password dumps. The easy come, easy go nature of bitcoin made it particularly lucrative.

Password reuse is a massive issue. At a glance, one might wonder why most sites need to care so much since they don't deal with money. Who cares about a forum like HN? But consider that it's easier to audit/impede new accounts with anti-spam measures, so there's value in taking over old accounts. And you don't want people with moderation tools getting attacked either. Ideally, it's nice to be able to trust an account with 1,000 posts more than one with 0 posts, but that evaporates when accounts are easily stolen.

Aside, how do you implement account-locking without making it trivial for users to DoS each other that way?

> Aside, how do you implement account-locking without making it trivial for users to DoS each other that way?

By adding an (increasing) time delay after each failed attempt. However many sites, banking in particular, just lock your account and you have to call them on the phone to reopen it. Totally open for massive DoS but the world still stands.

Well, that introduces trivial DoS, so it doesn't satisfy my question.

Notice that banking websites can get away with it, yet surely you weren't only talking about banking when you said "online attacks".

Sorry, I tried to say 2 things: 1. Your simple solution: add a 5 second delay after each failed attempt per username OR ip address. 2. It seems that sites that do account lock-outs don't suffer from DOS attacks, for some reason.

I'm not so sure about that. Hire time on a botnet so you have lots of IPs and start trying mixed usernames with mixed passwords. You won't have any choice over which username you eventually break in with, but I don't think you'd trip any alarms either.

Making credential stuffing harder is the main reason to do this. Credential stuffing works because users reuse credentials across sites. If someone attempts to use a password from the HIBP database, the two most likely cases are that it's extremely common or the same person is reusing it. Extremely common passwords are bad for all sorts of reasons and the same person reusing a breached password makes the account vulnerable to credential stuffing.

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.

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

>Why wouldn't they be?

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

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

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.

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?

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.

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.

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.