Credential Stuffing
18 comments
·October 13, 2025ArcHound
I am so happy I am no longer responsible for these. We had a solid monitor and an analysis script that was quite good at dealing with the attacks.
Then the fun thing was that some lawyers concluded this is still a breach on success and that we should be responsible and report/mitigate these.
How? How do you stop your users from making dumb decisions? The only solution seems to be to "give up" and go passwordless, putting the credentials to the big boys in town.
pankalog
Some years ago I researched the whole credential stuffing ecosystem for a course paper at uni.
Credential Stuffing is (or at least was) a gigantic market, and it is one of the biggest headaches for the biggest pay-walled services, like Netflix, HBO, Prime, etc.
The people that made a living out of it were stuffing millions or billions of credentials (sourced from database leaks) in the most popular services, hoping to then sell the accounts for small amounts of money, like a dollar for a Netflix account with a 10-day warranty. It's a numbers game at heart with a substantial technical aspect, where you need to optimize your checker code to essentially send properly formatted requests that can't be intercepted and don't arouse suspicion, and then you had an ecosystem of "methods" that are certain request-response chains that make your login request look like it's from a real person. People needed to figure out advanced methods to not invoke a CAPTCHA check, which is cost-prohibitive, but not impossible to solve automatically (AI wasn't a thing back then). You then have to buy millions of proxies that are able to route the requests from different IPs so that you're not sending millions of requests from a single IP. Checkers had reached a point where, depending on your proxies, were performing 10,000 or even 20,000 checks per minute. Multithreading was the cornerstone of these technologies, as a simple 2vCPU VM was already bottlenecked by proxy speeds.
Back when I looked into it, it was the wild west, as SSO and other technologies just weren't a thing yet. Companies would become fads of this credential stuffing scene, and it would take a dev team an entire sprint just for them to make a login page that was able to at least force a CAPTCHA check for each single request, and that's IF they had the proper monitoring tools to notice the gigantic spike in login requests. Having a valid account to a service like Ebay where you can then order whatever you want with the linked credit-card, you can understand how big of a security issue this is.
I haven't looked at it recently, but I assume that this has become vastly more difficult for the common-place services like streaming providers and digital goods marketplaces. SSO, IAM platforms like Keycloak, and advanced request scanning techniques have evolved. I'm guessing things have become substantially better, but it's always going to be a big issue for those smaller websites without a dedicated dev team or without at least someone maintaining them.
unethical_ban
More details on existing services or libraries for rate limiting would be nice. Still an informative article.
bobbiechen
The author, Dan, is at FusionAuth, so that might be a good place to start.
I work for Stytch (another CIAM provider) on the fraud and security side and we do these too. I'd say you see credential stuffing defenses integrated into the auth provider rather than standalone rate limiting because so much of the relevant context is tied up in the auth side.
And, all the error messages end up being bad, as is the case for many security things. For our own features like Intelligent Rate Limiting https://stytch.com/docs/fraud/guides/device-fingerprinting/d... it's usually a bad idea to tell a user "You hit the limit, come back in an hour or contact support" because it gives an attacker information on how to improve. And we regularly see probing behavior where an attacker is trying to find the edges of a defense before starting a full-scale attack.
On the side topic of error messages - if you've ever seen "If your account exists, the password has been reset" that's another useless error message because "No account exists with that email" enables account enumeration.
DarkNova6
Feels like LLM generated. I really would appreciate a TLDR.
gregoriol
tl;dr: "Credential stuffing is an attack where malicious actors use stolen username-password pairs from one service to attempt unauthorized access to other services. Unlike brute force attacks that try many passwords against one account, credential stuffing exploits the widespread problem of password reuse across multiple platforms. Defending against credential stuffing requires multiple strategies. Unfortunately no single defense provides complete protection."
jbstack
"Unfortunately no single defense provides complete protection"
For the server, maybe. For the user, a password manager (used properly) is a solid single defense solution.
IAmBroom
I first noticed this weakness when I was caught in a "password breach", which was really a fishing site for passwords.
I checked the list of passwords, and a significant amount had values like "uRFcWEBSITENAME".
I reasoned first they would try USERNAME, PASSWORD, and then try USERNAME with passwords updated for the other websites they were hacking.
Even the section of passwords beginning with just the first letter of WEBSITENAME was unusually large. Then I scanned for passwords containing the first few letters of WEBSITENAME... yup, a conspicuous lot of them. Those people at least tried to be smart about their password uniqueness, but it didn't really work.
rokkamokka
I'd argue that the really old custom of providing the user a fixed username (e.g. user ID) upon registration, and requiring that for login, provides complete protection vs credential stuffing. It has other drawbacks of course, which is why you rarely see it in use anymore...
mooreds
Do you mean a username that is distinct from email or phone number?
If so, why does that provide protection against credential stuffing? A username can be reused across different applications.
What am I missing?
IAmBroom
How does providing a predictable username protect against anything at all?
For us, introducing a simple device and location validation system (track which users log in with which devices and from where), combined with breached password detection from HIBP, which both can trigger an email validation code flow, practically solved the credential stuffing issues we had immediately.
For the user it's kind of a a soft MFA via email where they don't have to enable it, but also don't always get the challenge.
Astonishingly, we had barely any complaints about the system via customer care and also didn't notice a drop in (valid) logins or conversion rates.