Credential stuffing

Testing username-and-password combinations at scale that already leaked from another service. What it actually is, why it is not the same as brute force, and where it hits within an identity journey.

In short

Credential stuffing is the automated testing of leaked credentials against the login forms of other services. The attacker starts from lists of usernames and passwords obtained in previous breaches and tests them at scale, betting that the same combination gets reused in more than one place.

There is no guessing involved. The credentials being tested were already valid on some system, and what is being measured is how many people reuse a password.

It's not brute force, and the difference shows in the numbers

Both attacks test credentials against a login form, and that is where the similarity ends.

  • Brute force — it guesses. It tries many passwords against a single account until one works, so it produces high volume against few accounts and a minimal success rate.
  • Credential stuffing — it does not guess. It tries one or two already-valid credentials against a great many different accounts, so it produces low volume per account and a comparatively high success rate.

The operational consequence is concrete: a lockout control after failed attempts, the classic defense against brute force, barely notices credential stuffing. Each account receives one or two attempts, exactly what a legitimate user who mistyped once looks like.

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.

What reduces the exposure

A second factor that the leaked credential does not include. A valid password plus a factor tied to the device or to biometrics stops being enough to get in, which is why MFA changes the outcome of this attack more than any password complexity policy.

The full sequence, along with the patterns that give it away on the server side, is on the fraud-type page: credential stuffing.

Frequently asked questions

It is the automated testing of username-and-password combinations obtained in previous breaches, run against the login forms of other services. It works through reuse: a credential leaked on one site is still valid on another because the same person repeated it. The attacker does not break anything, they use something that was already valid.

Brute force guesses passwords against one account, with many attempts and a minimal success rate. Credential stuffing uses credentials that were already valid on another service and tests them against many accounts, with few attempts per account and a much higher success rate. That is why a lockout after failed attempts stops the first one and barely notices the second.

It stops the outcome, not the attempt. The credential is still valid and the attacker keeps testing it, but validating it stops being enough to get in when there is a second factor that was not part of the leak. Factors tied to the device or to biometrics are the ones that meet that condition: they do not leak alongside a password database.

One identity, one SDK

VU ONE brings identity verification, authentication and fraud protection together on a single identity graph.

The verification you run at signup stays available to authentication and to your fraud rules, with no repeated processes and no duplicated data.

Verify, Authenticate and Protect, consolidated in one place.

Request a demo