Why Magento's Customer Account Lockout Doesn't Stop Credential Stuffing

"We already have account lockout, so we're covered" is one of the more common misconceptions about Magento login security. Core's lockout is real and it works — for the one attack it was built for. Credential stuffing isn't that attack, and it walks straight past it.

What core's lockout actually protects against

Magento's built-in protection lives behind the customer/password/lockout_threshold and customer/password/lockout_failures config paths, and the logic sits in Magento\Customer\Model\Authentication. The mechanism is per-account: it counts consecutive failed password attempts against a specific, existing customer record, and once that count crosses the configured threshold, that one account gets locked out for a configured number of minutes.

That design assumes the attacker already knows which account they're trying to break into — a brute-force attack repeatedly guessing passwords for [email protected]. For that scenario, core's lockout does exactly its job: five or ten wrong guesses and that account stops accepting attempts.

Why credential stuffing slides underneath it

Credential stuffing doesn't guess passwords for a known account. It takes a list of email/password pairs already leaked from some unrelated breach — a different retailer, a forum, whatever — and tries each pair, once, against your login form, betting that some fraction of your customers reused that exact password. A single run might attempt three thousand different email addresses from one IP address, each one tried once or twice.

Run that math against a per-account counter: no single email address ever accumulates enough failed attempts to trip a lockout, because each one is only tried a handful of times. Most of those three thousand emails aren't even registered customers on your store at all — core's lockout logic only engages once it resolves to an existing account, so attempts against non-existent emails don't count against anything. The attacker can run the entire list against your store, uninterrupted, and core never once intervenes.

The tell is in the shape of the traffic, not the account. Credential stuffing looks like one IP address hammering the login endpoint with a high volume of distinct email addresses in a short window — not one email address getting hammered repeatedly. Any defense keyed to "how many times has this account failed" is structurally blind to a defense that should be keyed to "how many attempts has this IP made."

IP-based throttling as the missing layer

Rate-limiting by IP address closes exactly this gap: once an IP crosses a configurable threshold of login attempts in a rolling window — regardless of which email address each attempt targeted — further attempts from that IP get throttled or blocked outright. It doesn't care whether the emails being tried exist as customers; it cares about request volume from a single source, which is the actual signature of a stuffing run.

Applies to the standard customer login form at customer/account/login.
Also applies to the checkout login popup — a separate login entry point that a lot of bolt-on security tools miss entirely, and one credential-stuffing tools target just as often since it sits right at the point of purchase.
Runs alongside core's account lockout rather than replacing it — the two catch different attack shapes, and you want both active at once.

Stop the attack core's lockout never sees — before it ever reaches a single customer account.

Get Login Rate Limiter — free