Leaked credential checks at marketplace login: the free layer most sellers skip

Why seller accounts get stuffed first

Marketplace seller accounts hold two things an attacker can cash out quickly: a payout destination that can be edited, and a storefront whose reputation can be spent on listings the real seller never wrote. Credential stuffing fits that target because it needs no exploit. Lists of email and password pairs from unrelated breaches are replayed against the login page, and the pairs that still work open accounts at scale.

The replay traffic hides in ordinary login volume. Rotating residential proxies spread attempts across addresses, and the tools mimic browser headers well enough that a simple user agent block catches almost nothing. The signal that survives is the password itself. If the password arriving at your login was already exposed somewhere else, the person typing it is statistically far more likely to be holding a list than to be your seller.

What the check actually does, step by step

The check hashes the submitted password and queries a breach corpus with a partial hash, so the full password never leaves for a third party list in plain form. A match does not prove an attack is under way. Plenty of honest users still use a password that leaked years ago and have no idea. That is why the response should be a forced reset plus a fresh challenge, not a lockout that strands a legitimate seller mid listing.

Placement matters. Run the check on login, on password change, and on payout detail edits, because an attacker who gets in quietly often goes straight for the bank fields. A seller who passed login last month can still be the wrong person today if the session was hijacked, so the payout edit deserves its own check even inside an authenticated session.

Bot scores tell you when a campaign starts

Cloudflare treats a sudden spike in low bot scores, scores from 1 to 29, on a login path as an early signal of a stuffing campaign. One low score is noise. A rising share of low score logins outside your normal selling hours, clustered on one marketplace category or one country you barely sell into, is a campaign warming up. That is the moment to tighten rate limits on the login endpoint, not after support tickets arrive.

Rate limiting still earns its place, but aimed correctly. Limit by account identifier and by password hash as well as by IP address, because the proxy rotation defeats address limits on their own. Attackers testing thousands of pairs per second need volume; forcing each pair to arrive slowly makes the list economics collapse while a real seller, logging in twice a day, never notices the ceiling.

A forced reset that dumps a seller into a generic error loses the honest users and barely slows the attacker, who simply moves to the next pair. The flow that works says plainly that the password appeared in a known breach, sends the reset to the email on file, and holds payout changes for a cooling period after any reset. That hold is the unglamorous control that stops the money leaving while an account dispute gets sorted.

The reset flow is where you win or lose the seller

Measure it like an operator. Track the share of logins flagged as leaked, the share of those that complete a reset, and payout edit attempts within a day of a reset. If flagged logins stay high but resets stay low, your flow is broken, not your sellers. The check itself is cheap and often free at the CDN layer. The expensive part is a reset journey nobody tested on a phone.

Frequently asked questions

Keep reading: Triangulation scams: the marketplace seller who never touches the goods, Fake tracking numbers: the acceptance scan that never happens.