Credential stuffing

What credential stuffing is

Credential stuffing is the automated testing of username and password combinations that were already leaked from one service, against the logins of a different service, until the ones that work are found.

The premise behind it is behavioral, not technical: many people reuse the same password on several sites. The attacker doesn't need to break anything. They need a list and patience.

The detail that changes the whole analysis is this: the credentials being tested are valid somewhere. That separates this attack from any guessing attempt and defines how it is detected.

It is not brute force, and the difference decides detection

The two attacks look alike on a dashboard and behave in opposite ways. Confusing them is the most common reason a team believes it is covered and isn't.

• Brute force — the attacker doesn't know the password and searches for it. Many attempts against the same account, a very low hit rate. It leaves an obvious trail: one account with dozens of consecutive failures.
• Credential stuffing — the attacker already has the password and looks for where it works. One or two attempts per account, spread across hundreds of thousands of different accounts, with a comparatively high hit rate.

The practical consequence follows from there. A lockout after five failed attempts per account is a control designed against brute force. Against an attack that makes one attempt per account, that threshold is never reached, on any account, and the security dashboard shows nothing unusual.

The signal exists, but it isn't where it's being looked for. It doesn't appear on one account: it appears in the aggregate. A volume of login attempts far above normal, with an equally anomalous proportion of failures, spread across accounts with no relation to each other. Looking account by account, it's invisible. Looking at the hour's total, it jumps out.

How the attack runs, step by step

The sequence is industrialized and almost none of its steps require any particular technical skill.

1. Get the list. Email and password combinations from accumulated leaks at other services. They circulate aggregated, consolidated and sorted, and the largest ones are compilations of many earlier leaks.
2. Choose the target and study its login. How the form responds, whether it distinguishes between a nonexistent user and a wrong password, what messages it returns. That difference in responses is information the attacker uses.
3. Distribute the origin. Residential proxies, address rotation, variation of the browser and client fingerprint. The goal is that no single origin concentrates enough attempts to draw attention.
4. Try one or two combinations per account. Never more. The limit is deliberate: it keeps every account below any lockout threshold.
5. Separate the ones that work. The result is a short list of credentials confirmed on that service, far more valuable than the original list.
6. Use them or sell them. Direct use is an account takeover. Selling shifts the exploitation to another actor, sometimes months later, which separates the attack from its consequence and complicates the investigation.

Step 4 is what makes the standard control useless. Everything else is scale.

Where it shows up in an identity journey

Credential stuffing hits access, not sign-up. It shows up wherever there is a password to validate.

• Login of existing users — the direct target, and the path toward an account takeover.
• Access recovery — the same leaked data feeds the security answers and contact details that a recovery flow asks for.
• Less-monitored access interfaces — older applications and entry points left outside the rules of the main channel.

None of these moments involves identity verification. Credential stuffing does not attack proving who a person is: it attacks what the organization accepted as a substitute for that proof.

The attacked service was never breached

It's worth saying explicitly because it changes the internal conversation after an incident: when credential stuffing succeeds, the attacked system had no security failure. There was no intrusion, no exploited vulnerability and no data leak of its own.

What happened is that a person used their password in two places and one of the two was compromised. The service that receives the attack inherits the risk of a service it has no relationship with.

That has two consequences. The first is that hardening your own password policy, requiring more characters or periodic rotation, doesn't cover this attack: the leaked password already meets that policy. The second is that the only control that attacks the cause is to stop depending on a secret the person can reuse.

Who it affects and what it costs

The attack targets any service with username and password login, and the value of the target defines whether the attacker tries it.

• Retail and e-commerce — accounts with saved payment methods and loyalty programs, which are the most frequent targets because the balance is almost never checked.
• Betting and gaming — accounts with funds and with identity verification already done, which makes them reusable for other fraud.
• Financial services — less exposed to direct access because of two-factor authentication, but equally affected by the cost of the flood of attempts.
• Subscription and content services — resale of access, which is low unit value, high volume fraud.

There is a cost that shows up before any fraud and is usually the first to be noticed: infrastructure. An attack of this shape generates a spike in login attempts that degrades performance, triggers alerts, saturates logs and sometimes affects legitimate users through containment measures applied in a hurry.

What controls stop it

The defense is split between the network layer, the login layer and the design of the credential. The three parts are bought in different places.

• Rate limiting by origin and by origin group — not by account, which is where the attack hides. It is implemented at the edge, in the content delivery network or in the web application firewall. An identity provider doesn't supply it.
• Bot management — client fingerprint analysis, automation detection and progressive challenges. It is a product category of its own, with specialized vendors.
• Anomaly detection in the aggregate — watching the proportion of successful logins over the total and the curve of attempts per hour, instead of looking account by account. It is the control that makes visible what the threshold doesn't see, and it is often the work of internal analytics, not of a purchased product.
• Checking against corpora of leaked credentials — rejecting at signup and at password change any key that appears in known leaks. There are public and commercial services that expose that check without receiving the password in the clear. It is the measure with the best cost-to-effect ratio, and a biometrics provider doesn't sell it.
• Uniform responses on the login form — the system shouldn't distinguish between a nonexistent user and a wrong password, neither in the message nor in the response time. It takes the information from step 2 away from the attacker.
• A second factor that can't be dictated — turns a valid credential into an insufficient one. A factor the person can read and dictate is still vulnerable to phishing, but against credential stuffing any second factor is already a real barrier, because the attack is automated and has no one to ask for the code.
• Device and session signals — a never-seen device, inconsistent geolocation, a navigation sequence impossible for a person.
• Step-up on the sensitive operation — asking for presence again at the moment of the transfer or the redemption, not only at login.
• Removing the password — a passwordless login has nothing to stuff. It is the only control that attacks the cause instead of the consequence.

The two controls with the most immediate effect, rate limiting at the edge and bot management, are bought from infrastructure and web security vendors. A team that expects to solve credential stuffing with its identity provider will cover the stretch after login, not the traffic spike that precedes it.

How VU approaches it

VU works on the credential and on what happens after login. The network layer is covered by a different kind of vendor.

Authenticate supports passwordless authentication with seven available factors: face, TOTP, OTP by SMS, OTP by email, magic link, password and identity document. A login that doesn't use a password leaves a list of leaked passwords with no purpose, which is the definition of the attack.

Where the password is kept, the second factor is what prevents a valid credential from being enough. Against an automated attack, even the factors weakest against phishing work, because there is no person on the other side to ask for the code.

Protect against fraud evaluates risk signals on the device and the session, which is what separates a login with correct credentials made by their owner from one made by whoever bought them.