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.
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.
DarkNova6•1h ago
gregoriol•54m ago
rokkamokka•36m ago
mooreds•19m ago
If so, why does that provide protection against credential stuffing? A username can be reused across different applications.
What am I missing?
jaratec•3m ago
No, he means a unique user id, generated by the server when you sign up for the service. Then for every login attempt, you provide the username/email + user id + password.
IAmBroom•7m ago
aetherson•1m ago
jbstack•21m ago
For the server, maybe. For the user, a password manager (used properly) is a solid single defense solution.
IAmBroom•8m ago
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.