Background: I spent years developing a product that currently defends F500 websites against automated attacks. If you live in the US you've more than likely used my software this week without knowing it.

Rate limiting is completely ineffective in preventing credential stuffing attacks from determined adversaries. The challenge is not brute-forcing, but credential leaks and password reuse. Attackers have access to vast seas of IP addresses and in my past life doing the defending, we would see an IP address involved in automation twice, and then it would go away forever.

I've covered this in a reply to another one of your comments, I think, so won't bother here.

> This is only truly necessary as a mechanism to prevent automated signups.

Only if there isn't some shared knowledge between the website and prospect.

For example some niche websites that I use have locally-based challenges such as 'how many engines can be fitted to a Boeing 747-400'* or a short mathematical algebra to solve.

Both approaches work without Javascript and without external support, just with a two-column table and a trusted group of challenge-creators.

* it's more than four

Rate limiting login attempts means I can prevent you from logging in indefinitely by pushing your account into the rate limited status.

Only as long as you keep up the attack.

But an attack that keeps rate limits saturated doesn’t require much bandwidth (you know, because rate limits) and is therefore easy to keep up. Most services would consider it unacceptable if a script kiddie with a botnet and a generic list of usernames were able to prevent even 1% of their users from logging in.

So your solution is "sorry, come back later when the attacker hopefully stops"?

I can keep you out of your account indefinitely with a curl loop and a rotation of proxies?