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.
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.
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.
Oh boy this was a major problem at our budding fintech. Here's what DIDN't work:
1. Browser fingerprinting or ip bans. They used advanced fingerprint-shifting browsers and residential proxy ips.
2. Phone number 2FA. Significantly slowed legitimate user access but still didn't fully stop credential stuffers.
What did work:
3. rate limits and carefully tailored scripts that detected usage patterns and autobanned. Eventually they gave up on us guess wasn't worth the trouble. However I'm sure we lost a few legitimate users too in the process.
What I would try in the future:
- Passkeys as 2fa. Most browser automation platforms can't handle passkey auth inside a VM.
Not sure why financial institutions still bother with passwords - every time i try to login to wise or something it requires email code/link. At that point just use the email auth.
Solutions exist that can completely block credential stuffing attacks most people just don't know about them, for example: https://layer3intel.com/tripwire
at my first job I was able to identify a remote username enumeration vulnerability which, when combined with cred stuffing based on some publicly known cred dumps, netted me a couple dozen good user accounts on our web app. we ended up rate limiting login attempts and adding random delay to failed logins to mitigate the username enumeration vuln (tldr - if you sent creds w a nonexistent username the system immediately failed the login attempt, but if you sent w a good username and any password the system had to take time to hash and salt your password then compare it to the stored hashed passwords, so attempts w a good username have a much higher latency than w a bad one)
I remember dealing with a large credential stuffing attack at a marketplace right after we announced our series B ~2018. We developed some tools to keep them out through pattern matching, but it was not easy and it took some time to develop those tools.
Best companies to work with were spycloud.com and sift.com.
spycloud actually specializes in identifying leaked credentials, which are what attackers use in the credential stuffing list they go through, so you could identify "stuffable" credentials prior to the attack happening, which is nice.
sift was great at helping to just identify fraud in general, so if an account did quietly get compromised, we could identify it before the transaction was finalized.
14 comments
[ 1.8 ms ] story [ 37.4 ms ] threadCredential 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.
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.
I guess ChatGPT doesn't know that one, yet.
How are you securely delivering the password to the end user? How are they securely storing a string you created? One that is presumably high-entropy?
Or are you talking about one time use passwords (OTP)?
1. Browser fingerprinting or ip bans. They used advanced fingerprint-shifting browsers and residential proxy ips.
2. Phone number 2FA. Significantly slowed legitimate user access but still didn't fully stop credential stuffers.
What did work:
3. rate limits and carefully tailored scripts that detected usage patterns and autobanned. Eventually they gave up on us guess wasn't worth the trouble. However I'm sure we lost a few legitimate users too in the process.
What I would try in the future:
- Passkeys as 2fa. Most browser automation platforms can't handle passkey auth inside a VM.
Best companies to work with were spycloud.com and sift.com.
spycloud actually specializes in identifying leaked credentials, which are what attackers use in the credential stuffing list they go through, so you could identify "stuffable" credentials prior to the attack happening, which is nice.
sift was great at helping to just identify fraud in general, so if an account did quietly get compromised, we could identify it before the transaction was finalized.