[metildaa]

Rate-limiting & banning after repeat failed login attempts should be the baseline moat an IT admin or selfhosted infrastructure should have.

Fail2ban rules like "after 5 failed logins, ban for 30min, 10 failed logins in a day (with no succesful login) is a permaban" will curtail most non-spear phishing attacks.

[deogeo]

A permaban is an awful idea. A legitimate user who forgot their password can easily go through more than 10 failed attempts as they try variations of what they think their own password might be.

"I know I used my usual password, but did it start lower or upper case? Or camel case... did I end it with a number? Did the service require a special symbol, so I added that to the end? Or to the beginning.." - banned.

[metildaa]

Hence following current NIST guidelines which do not require regular password changes, capitals, special characters or numbers in passwords: https://www.enzoic.com/surprising-new-password-guidelines-ni...

Don't be a PITA to your users, and you've eliminated most of the "guess what password you used" game.

[Polyisoprene]

Or getting your account banned after someone failed trying to brute force it and not being able to access it due to changes in security policies.

[metildaa]

Fail2ban bans an IP address or range of IPs, not specific users.

[hombre_fatal]

That advice is pretty antiquated.

The reality is that, these days, I rent $5 worth of botnet time and make {user,password} combo login attempts from thousands of residential IP addresses.

You might think your advice is a good "might as well" elementary, but generally if people want to curl your /login page from their laptop, then they are also buying $5 scripts off Hack-Forums that automate botnet cred stuffing against your service as well. And you'll need a better gameplan than fail2ban.

[tialaramex]

Use something like random token buckets not simple rate limiting.

If a user fails credential checks (e.g. password), track it, if their current failure rate is N, tell them they tried too many wrong credentials, come back later. Every random(1,T) seconds any failed users get their failure count reduced by one until it's zero and you stop tracking it for now.

By choosing N and T you can give users a relatively large number of "goes" to remember their password after a long period away, but not give attackers too many chances to guess a not-awful password by brute force.

For example if N is 10 and T is 7200 then a user can try ten passwords, then an average of 24 more attempts per day but exactly when they can make another attempt is random. This allows your good guys to have a fair chance against any bad guys smashing the "retry" button to try to lock them out. If the bad guys give up and go away, the user quickly returns to having ten attempts.