Let’s End Credential Stuffing Breaches

If you’re responsible for protecting user data on a web application or SaaS service, this article is mandatory reading.

What do each of these websites have in common?

• 23andMe
• PayPal
• Norton LifeLock
• North Face
• Hot Topic
• DraftKings
• Iconic
• Jason’s Deli
• PetSmart
• Roku

They, and more importantly their customers, all needlessly suffered Credential Stuffing breaches in 2023-2024. At least one of these companies - the one you’d think might have the best security measures in place - had the gall to blame their own customers. There is at least one class action lawsuit in the works.

The kicker? A single, simple, and free security measure would have prevented these breaches.

The hard fact is Credential Stuffing breaches should’ve ended in 2017, if not before.?

Individual users - it’s also easy to protect yourself!

1. For each website, use a long, unique, and complex password, preferably created by a password manager. If you’re using a compromised password on a website, your account and data are at risk. That’s not just a password you have used before, but any password that anyone has used before, anywhere, which fell into the hands of bad actors. Check if your password is compromised here.
2. Set up multi-factor authentication where available and appropriate.

So many more suggestions here, but it’s beyond the focus of this article.

Let’s take a look at what Credential Stuffing really is.

In short: Bad actors take known-to-be-used credentials and “stuff” them into login forms on other websites, in hope that the same username and/or password is used across multiple websites.?

Over the years, the bad actors:

• Nefariously obtain users’ usernames/passwords (e.g., hack into websites, info-stealing malware on computers)
• Compile those usernames/passwords into datasets (i.e., breach dumps)
• Distribute those datasets underground (e.g., dark web)

The end result are massive lists of usernames and passwords that are known to be used on the internet. How massive? Over a billion. And they just keep coming. It’s relentless. In the last couple weeks we’ve seen the massive Naz.API Credential Stuffing List and what's being called “the mother of all breaches”, with 26 billion records (not all unique).

Here’s an ultra-simplified sample:

+------—------—------—---+
| sam     | password     |
| sally   | password!    | 
| steve   | password123  |
| sue     | Password123$ |
+------—------—------—---+        

Come on now - who hasn’t used ‘password’ at some point? Who could blame you - it was the default password for enterprise gear for decades. The tech industry has taken forever to come around to Secure by Default.

These datasets can be usernames only, passwords only, or both. They can contain email and other attributes as well.

So the bad actors have a bunch of credentials. Now what?

The key is these credentials are known to have been used before. So they “stuff” those credentials into login forms on other websites in order to brute-force into other peoples’ accounts, with surprisingly successful results. This works for a couple reasons:

• People use the same, non-unique password across multiple websites.
• We as humans think alike and create the same, terrible passwords as each other.

Bad actors mix and match usernames and passwords using every possible combination. If a login form unintentionally leaks that a username is in use, then half of the equation has been solved - only the password remains.

They may try to fly under the radar, at least for a while, but eventually they’ll unleash an army of bots. Your site may see hundreds, thousands, or millions of login attempts per minute.

They could utilize anything from a solitary computer to hundreds, thousands, or even millions of bots. Authentication requests will be distributed amongst their fleet to optimize their campaign for best possible results. They can scale up or down, adding as many bots as they deem necessary to get their payday.?

Your site may slow to a crawl.

You would expect that this excessive authentication activity should trigger alerts. At the very least, you would think someone would be watching metrics and logs for anomalies and notice. Based on the plethora of Credential Stuffing breaches in the news, apparently not. And that seems like a dereliction of duty.

So, how do we stop these attacks?

SIMPLE! Don’t allow logins for breached passwords.

As mentioned at the beginning, this was solved for us in 2017:

• NIST guidance outlined the solution in June 2017.
• Troy Hunt made this capability ubiquitous to all only 2 months later in August 2017.

NIST guidance is to check the passwords against breach corpuses at the establish and change steps, but going a step beyond and checking at the login step is what actually prevents Credential Stuffing attacks. With new breach dumps being released frequently, a password could change from “secure” to “known-compromised” from one day to the next. So a password you allowed someone to create last month could no longer be safe.

Let’s dig in!?

As we touched on above, these compromised passwords are already known as these breach databases are shared underground.

Since we can use the same breach dump databases as our adversaries, we simply add a step to the user/password verification process that checks if the password is compromised.

Only a small bit of logic needs to be added to the login procedure - and no more Credential Stuffing breaches! ?

Here’s what this login process would look like:

The “Check Password in Breach DB” step can be done with a locally-saved breach database (free) or via remote API call (very nominal fee). The remote API calls are secured with k-anonymity - no shooting users’ passwords all over the internet. Remote API call fails because of an outage? Your call whether to fail open or fail closed - it’s sometimes a delicate balance between data protection and end-user frustration. Aside from HIBP, there are many other options on the market to check against compromised password databases these days.

Our job is done, right?

Our jobs is never done. This shouldn’t be your only line of defense. This is a cat-and-mouse game, so hackers could have newer passwords than we do. The 80/20 rule applies here - and I’d dare say this is the 1 thing that yields 99+% protection against Credential Stuffing. But we can do more!

Here are some other mitigation techniques to protect against Credential Stuffing other nuanced brute-force website authentication attacks, including password spraying (slow, targeted attack against a smaller number of known high-value accounts):

• Alert on anomalous increases in traffic, especially to authentication endpoints.
• Don’t leak whether a username exists in your login or password/account recovery forms. That’s half of the username/password pair, and jeopardizes user privacy.
• Inject a randomized 1-4 second delay on initial authentication requests. This prevents leaking whether a username exists due to a timing attack, but also slows bad actors.
• Incrementally increase the delay for subsequent failed authentication requests from the same IP or for the same username.
• Lock user accounts after multiple failed login attempts. Start with a short temporary lock, leading up to a permanent lock. You’ll have to decide on different thresholds for lock duration based on fail count and attempt timing/volume. Make sure to check over long periods to prevent slow password spray attacks. Here are some examples:

5 failures in 5 minutes

10 failures in 20 minutes

20 failures in 24 hours

40 failures in 7 days

• Block IP addresses after:

1) multiple “invalid username” login attempts

2) multiple failed login attempts

Use different durations based on thresholds around attempt timing/volume, leading up to a permanent block of the IP address, especially for multiple infractions. To be on the safer side, consider only blocking IP addresses without a history of successful user logins.

• Send alerts when an abnormal number of user accounts or IP addresses are being blocked.
• Implement GeoIP blocking
• Use a CAPTCHA in your login form (Yuck, I know!)
• MFA!

The tips above and suggested thresholds will need to be tailored to your service and customer base. Implementing just these delay and blocking countermeasures by themselves - even without blocking compromised passwords - will thwart most credential stuffing attacks. The key takeaway with these is: the more stumbling blocks you put in the way, the sooner bad actors go elsewhere looking for easier prey.

Wrapping up...

Everything so far in this article suggestions can be implemented for free, or very little cost - and some engineering time. Some paid options worth considering include Bot Management services, Web Application Firewalls, and API Gateways.

Of course the overall security of your web application is subject to its weakest link. Make sure it’s hardened to modern standards with a holistic application security program, including regular vulnerability and penetration testing. Here are a couple starting points:

• https://cheatsheetseries.owasp.org/IndexTopTen.html
• https://relevant.software/blog/saas-application-security-guide/

By proactively implementing the simple yet effective security measures outlined in this article, we can strengthen our defenses - and with any luck - put an end to credential stuffing breaches!