[yashap]

Besides 2FA, rate limiting your login endpoint (both by IP address and username) is a much more robust protection against this attack. Especially if you include temporary bans (e.g. “20 failed login attempts with the same IP, and/or same username, in the past minute = 15 minute ban for that IP and/or username”). A lot of API gateways, K8s ingresses, etc. make this dead simple, and if not it’s also super easy to add with a few lines of code and something like Redis to store counts of recent login attempts.

I do think checking against the HIBP DB is a good call too, but it doesn’t stop this attack overly well, rate limiting is a much better way to stop it.

[aaronharnly]

Rate limiting definitely helps against credential stuffing in the form of trying a bunch of common passwords against random accounts.

But there's also "stuffing" with known breached username+password combinations – in which case it still helps, but I don't think as much? In the latter the attack is much more likely to succeed and there's a much smaller number of values being attempted, so the threshold of detection + blocking would have to be much lower...

[yashap]

Yeah, I do think it's worth doing both :) As well as at least making 2FA an option for your users - 2FA is the ultimate defence to most of these problems, but depending on the company/use case, not everyone is willing to make it mandatory, it does tend to be a lot more annoying to users. Things like failed login rate limits, minimum password length/complexity, and banning known breached logins is less intrusive to the user, and still pretty good defence when combined, though not as good as 2FA.

[themoonisachees]

The threshold is lower but in reality it still makes considerably more login attempts, many of them failed, than a normal client ever would. Credential stuffing attacks don't really limit themselves to a single account, even if it worked.