Credential stuffing attacks: How they work and how to stop them

What a credential stuffing run looks like from the attacker's side and in your logs, why reused passwords make it work, and five controls that cut the hit rate.

6 mins readPublished Updated
On this page
  1. What is credential stuffing?
  2. How a credential stuffing attack runs
  3. Why the attacks succeed
  4. Why it matters to a business
  5. How to reduce the risk of credential stuffing
  6. Where to start

Credential stuffing is the attack behind most account takeovers. An attacker takes username and password pairs leaked from one breach and replays them, by the million, against the login forms of other sites. It works because people reuse passwords. One Statista dataset on login attempts by industry put credential stuffing at 91 percent of login traffic at ecommerce sites.

What is credential stuffing?

Credential stuffing is an automated login attack. The attacker does not guess passwords; they already have them, taken from breaches of other services, and they test which ones still work on yours. It is not new, but the supply of leaked credentials and cheap automation has made it routine against any login form.

Bots do the work. They rotate proxies and user agents to look like thousands of ordinary visitors, submit the pairs at a steady pace, and log the hits. Ecommerce sites draw the most of it because a working login sits next to a stored card.

How a credential stuffing attack runs

Picture a burglar with a sack of keys taken from other houses, trying each one in your front door. Most will not fit. Some will, because people cut the same key for every lock they own.

The run has four steps. The attacker buys or downloads a combo list: email and password pairs from past breaches, often hundreds of millions of lines. They load it into an automation tool. They point it at a login endpoint through rotating proxies, so no single IP trips a rate limit. The tool records every pair that returns a working session, and that list of live accounts is what gets used or resold.

From the victim's side it looks like this. You used one password on a forum years ago and on your email, your shop account and your bank since. The forum was breached. Months later someone logs into the shop account from a device you have never owned, changes the shipping address and buys with the card on file. The password was never guessed; it was looked up.

The fix on the user side is unglamorous: a different password for every site, a password manager to hold them, and a second factor wherever it is offered. The fix on the site side is the rest of this post.

Why the attacks succeed

They succeed because people reuse passwords, and because most login forms cannot tell a replayed credential from a typed one.

Everyone has done it: signing up for a new site with the password that already guards the bank account. If any one of those sites leaks, every other account with that password is open to anyone holding the dump, and the login looks legitimate because the password is correct.

A 2021 SecurityIntelligence article put credential theft in 81 percent of hacking-related breaches, and 85 percent of people admit to reusing passwords across sites. The two numbers are the same story from either end.

A unique password per site turns one breach into one lost account instead of ten.

Why it matters to a business

The attack is cheap, it scales, and the accounts it opens are worth more than the credentials that opened them.

Cheap: a combo list costs little or nothing, the tooling is free, and proxies are rented by the hour. Nothing special is needed beyond a leaked list and a target.

Scale: one run can test thousands or millions of accounts in a session. Even a tiny hit rate on a million pairs is a long list of working logins.

Value: the account behind the login holds whatever you stored. Many companies keep detailed customer records, including card numbers and in some cases social security numbers, so a single working login hands over an email address, a payment method and enough personal data to open the next account somewhere else.

Attackers combine that with other breached data to build complete identity profiles, which is where the money is.

How to reduce the risk of credential stuffing

Five controls, roughly in order of effort.

1. Turn on multi-factor authentication, and read up on the bypass techniques attackers use against it so you pick a second factor that holds.

A correct password is no longer enough to get in, which removes the point of the combo list. You do not have to challenge every login. Ask for the second factor when the device, network or behaviour does not match the account's history, and most customers never see it.

2. Know what the attack looks like in your own logs.

A stuffing run shows up as a surge of login attempts, a failure rate far above normal, many accounts touched from few IPs or many IPs hitting at machine pace, and a user agent mix that does not match your real traffic. If nobody on the team has looked at a login dashboard with this in mind, that is the first afternoon's work.

3. Check that the third-party services holding your users' credentials do the same.

Any vendor that accepts a login from your users is part of your login surface. Ask what they do about automated logins and check the answer rather than taking their word for it.

4. Limit failed login attempts per account and per source.

A cap on failures slows brute force and makes a stuffing run noisy. Set it per source as well as per account, because a stuffer tries each account once and moves on, so a per-account cap alone never fires. Lock out with care: a lockout an attacker can trigger on purpose becomes a denial-of-service tool against your own customers.

5. Monitor logins and alert on anomalies.

Watch failed-to-successful ratios, new-device logins and logins from networks that do not fit the account, and route the alerts to someone who can act in minutes rather than a weekly report. This is the layer that catches the pair that was correct and arrived from a clean proxy. See bot attack prevention for how device and behaviour signals separate a checker from a customer.

Where to start

As a user: a password manager, a unique password per site, and a second factor everywhere it is offered. As a business: assume the passwords in your database are already in someone's combo list, and build the login so a correct password alone is not enough.

Start with the login logs this week, then add a second factor on risky logins. To see how Sensfrx scores each login from device, network and behaviour signals, read about account takeover protection.

Written by

Srivani Reddy

Security researcher

Part of the security research team behind Sensfrx, with a penetration-testing background. Writes about fraud detection, bots and account security.

See how Sensfrx scores every signup, login and payment in real time.