When the password is already stolen

The most common way into a web application is not a clever exploit. It is a correct password, typed by the wrong person. Reused across sites, leaked in someone else's breach, and replayed against your login until one of them works.

This is credential stuffing, and it works because people reuse passwords and because most login forms will take an unlimited number of guesses without complaint. An attacker does not brute force a single account. They take a list of a million known email and password pairs and try each one once, quietly, from a different address every time.

The login form is not the flaw

There is nothing wrong with the password field. The credentials are real. The failure is that the application never notices the shape of the attack: thousands of sign-in attempts, each with a different valid-looking email, most of them failing, a few of them landing.

POST /login   alice@example.com : hunter2      -> 401
POST /login   bob@example.com   : password1    -> 401
POST /login   carol@example.com : letmein       -> 200   <- one lands
...  1,000,000 pairs, one attempt each, no limit hit

No single request is suspicious. Together they are the entire attack, and an application that rate limits per account rather than per source never sees it, because no account is tried twice.

What we test

We test whether the login, the password reset, and the multifactor step will let one source make thousands of attempts. We check whether a failed login and an unknown email give different answers, because that difference hands an attacker a list of which accounts to bother with. We test whether multifactor can be skipped, replayed, or turned off from an endpoint that forgot to ask who was calling.

Then we look past the front door, at what a landed login is worth. Does the session it hands out survive a password change? Can the same token be used from two places at once? A stolen password is the start; the damage depends on how much a single valid session is trusted, and for how long.

reset code accepted 5 times          -> reusable
MFA endpoint /disable, no re-auth    -> bypass
session still valid after password change  -> stolen access persists

You cannot stop people reusing passwords. You can stop a million guesses from costing nothing.

The fix is not a harder password policy, which mostly punishes your real users. It is limits that count attempts across sources, answers that do not reveal which accounts exist, a multifactor step that cannot be walked around, and sessions that end when they should. We test each of those against your application and tell you which guess, on which endpoint, the attacker gets for free.