Modern cred stuffing is done by botnets. When I see a cred stuffing attack, it's maybe 1-3 attempts per IP address spread over 100-500k IP addresses.
Often you'll have a family of legitimate users behind an IP address that's cred stuffing you at the same time.
Throttling by IP address may have worked 10 years ago, unfortunately it's not an effective measure anymore.
Modern cred stuffing countermeasures include a wide variety of exotic fingerprinting, behavioral analysis, and other de-anonymization tech - not because anyone wants to destroy user privacy, but because the threat is that significant and has evolved so much in the past few years.
To be entirely honest, I'm kinda surprised Google didn't require javascript enabled to log in already.
Unfortunately I don't have much reading material to provide. It's a bit of an arms war, so the latest and greatest countermeasures are typically kept secret/protected by NDA. The rabbit hole can go very deep and can differ from company to company.
The most drastic example I can think of was an unverified rumor that a certain company would "fake" log users in when presented with valid credentials from a client they considered suspicious. They would then monitor what the client did - from the client's point of view it successfully logged in and would begin normal operation. If server observed the device was acting "correctly" with the fake login token, they would fully log it in. If the client deviated from expected behavior, it would present false data to the client & ban the client based on a bunch of fancy fingerprinting.
Every once in awhile, someone will publish their methods/software; Salesforce and their SSL fingerprinting software comes to mind: https://github.com/salesforce/ja3
A relatively successful company in the area is Shape Security. Their marketing is a bit painful, but they invented the concept of cred stuffing. Disclaimer: I worked there for four years.
Fundamentally it's a question of fingerprinting the behaviours of humans versus bots. The problem is that it's becoming increasingly difficult to distinguish them, particularly when bots are running headless chrome or similar, and real users are automating their sign-ins with password managers.
I don't do much of this sort of thing, but numerous things come to mind. Aim to identify and whitelist obviously human browsers, blacklist obviously robot browsers, and mildly inconvenience/challenge the rest.
For example, an obvious property of a real human browser is that it had been used to log in successfully in the past. Proving that is left as an exercise for the reader, though it inevitably requires some state/memory on the server side.
Throttle based on what? IP address? This works for domestic IT departments looking to shut out automated attempts from specific ranges but at Google's scale IP based filtering could end up shutting out an entire country.
That's a terrible idea. Back when MSN was one of the most common instant messengers, there was a common prank that was called "freezing" where you just continuously kept trying to log into someones account and it would lock itself out for 15mins or more depending how long you kept doing it.
That's the first obvious countermeasure and will prevent hackers targeting a specific account. But there are other ways to crack passwords, one is to try the same password but iterate over user ids instead. As hackers would start with the most common password you can't throttle globally on same password attempts either because well yeah, it is by definition the most commonly used one which should have a lot of traffic.
This has nothing to do with anything but I don't know how else to get in touch with you. Could you upload your zero spam email setup guide somewhere? Your site was hacked so the link I had doesn't work:
"Credential stuffing" as I've heard it used refers to taking username/password combos from one breached site and trying them in other sites.
So for example LinkedIn has a breach, which reveals to evildoers that user 'johnsmith@example.com' uses the password 'smith1234' then they test that username and password in Amazon, Netflix, Steam and so on.
They only make one attempt per account, because they only have one leaked password per account. Hence, throttling per account isn't an option.
All of Qatar's traffic used to be routed through 82.148.97.69, though that was back in 2006-2007. At one point it was banned from Wikipedia, which unintentionally affected the whole country.
Why is it not sufficient simply to throttle logins at the server?