In 2019, Recorded Future's Insikt Group priced the credential stuffing supply chain end to end and found that $550 of tooling could return at least twenty times that on the resale of compromised accounts. Seven years on, most of the tools it named are given away free, and the credentials they consume have multiplied.
Over the same period competition drove the price of a compromised account of the kind that has a resale market, meaning streaming, gaming and marketplace logins, from over $10 down to between $1 and $2. Combo lists of a million credentials trade for a few dollars.
None of which would concern a Shopify merchant except that their store has a login form, an account registration form and a password reset form, all three publicly addressable, and all three attract this traffic whether or not the store holds anything worth stealing. Account takeover on a small store is not targeted. It is a by-product of a campaign running against thousands of sites at once.
The tooling, and what it sells for
The software is neither exotic nor hidden. Insikt Group's 2019 survey named the tools and quoted the prices, and they were modest even then.
Sentry MBA, one of the longest-running account checkers, is distributed with over a thousand configuration files; individual configs sold for between $5 and $20. SNIPR, written in C and supporting both online stuffing and offline dictionary attacks, retailed at $20 and shipped with more than a hundred configs. Private Keeper, popular in Russian-speaking forums, was priced from around eighty US cents. One tool the researchers examined sold for $12 and cleared a list of several thousand addresses in under two minutes.
Those prices are historical, and the direction of travel since has not been the one a vendor would prefer to report. Sentry MBA is largely defunct. OpenBullet 2 and SilverBullet, its successors, are free and open source. The tooling did not get cheaper so much as go to zero, and the money moved one step along the chain. The config, not the checker, is what the market actually prices.
"A working config for a specific target represents the reverse-engineering of that target's anti-bot stack: which CSRF tokens to grab, which fingerprint values to send, which proxy types still work, which response shapes correspond to which outcomes. Configs for popular targets are sold for $50 to $500 each. Configs for new targets get released within days of any anti-bot deployment that breaks the previous one."
Foil, security vendor documentation, Credential stuffing, May 2026. We have not been able to verify this price range against a second source and it should be treated as one vendor's estimate.
That is the competitive dynamic. A defence is broken once, and the break is then sold on to people who could not have produced it. The relevant question for a merchant is therefore not whether their protection can be broken, but whether their store is worth someone writing a config for. For most stores it is not, which is why ordinary defences hold.
The cost stack
Set out end to end, the inputs are individually cheap. Below is the stack, sized for a campaign of one million login attempts spread across many targets rather than aimed at one store. Tooling prices are 2019 figures; proxy and solver rates are 2026. Both figures below are models built from published rates, not measurements of any specific campaign.
Free tooling and config, cheapest proxies at the low end; realistic bandwidth at the high end $10–$70
Against that outlay, the return, and then the same return once the merchant charges for entry. Published hit rates for credential stuffing run between 0.1 and 2 percent, depending on the freshness of the list and the target. For the challenged column we have used $1.50 per thousand solves, the rate we established in our first dispatch, applied to every attempt.
| Hit rate | Accounts | If every hit resold at $1–$2 | Against $22, no challenge | Against $1,522, challenged |
|---|---|---|---|---|
| 0.1%stale list, hardened target | 1,000 | $1,000–$2,000 | 45× to 91× | 0.7× to 1.3× |
| 0.5%typical | 5,000 | $5,000–$10,000 | 227× to 455× | 3.3× to 6.6× |
| 2.0%fresh list, weak target | 20,000 | $20,000–$40,000 | 909× to 1,818× | 13× to 26× |
Three forms, three purposes
On a Shopify storefront this traffic arrives through three forms, and merchants tend to notice only the symptoms rather than the mechanism.
Login
The credential stuffing target proper. Pairs from a combo list are replayed against your customer base to find password reuse.
What you seeA failure rate far above normal, thousands of distinct addresses, roughly one attempt each.Registration
Disposable account creation. Sometimes the goal itself, often a side effect of checkout bot activity that creates an account per attempt.
What you seeHundreds of accounts with no orders, no sessions and addresses at disposable domains. It is also the most reliable enumeration oracle you have, because "this email is already registered" confirms an account exists.Password reset
Two uses. Enumeration, to learn which addresses have accounts. And amplification, because each request sends mail from your domain to an address the attacker chose.
What you seeReset requests for addresses that have no account, in volume.All three are ordinary Shopify storefront forms. Unlike the checkout endpoint examined in our fourth dispatch, they can be scored, rate-limited and gated by anything a merchant chooses to install.
Score login, registration and password reset before the next list runs
Spambuster puts invisible Google reCAPTCHA on all three account forms, plus contact, newsletter, comments and reviews. It provisions its own keys, logs every decision with the score behind it, and never shows a real customer a puzzle. Basic is $3 a month. A year of it costs less than the proxy bandwidth for a single campaign.
Start the free 14-day trial →Telling it apart from real traffic
Credential stuffing is easy to identify once you know to look at the ratio rather than the volume, because it inverts the normal shape of login failure.
A real customer who cannot log in fails several times on the same address, then requests a reset. Credential stuffing produces the opposite: an enormous number of distinct addresses, each attempted once or twice, with a failure rate that in a serious campaign runs well above 90 percent. A login form whose failure rate has moved from a normal ten or fifteen percent to ninety is not experiencing a usability problem.
The other reliable signature is on the reset form. A burst of password reset requests for addresses that have no account on the store is enumeration, and it usually precedes something else.
One practical caveat. Shopify does not expose customer login failure logs to merchants, so the ratio described above is not something most readers can query directly. What is visible in the admin is the Customers list, where a stuffing or registration campaign shows up as a cluster of accounts with no orders, no sessions and addresses at disposable domains, created within a narrow window. If you run a form-scoring app, its own decision log is the other place the pattern appears.
Credential stuffing succeeds against password reuse, which means a successful hit on your store is also a successful hit somewhere else. Force a reset on affected accounts, and be careful how you word the notice: telling customers their account "was accessed" without explaining that the password came from another service's breach tends to produce the conclusion that your systems were compromised. They were not, and saying so plainly is fair.
Do not assume that distinction discharges your obligations. Unauthorised access to customer data you hold can still be a notifiable breach under the GDPR, the Australian Notifiable Data Breaches scheme and several US state laws, regardless of where the password came from. We are not lawyers and this is not advice. Take some before deciding not to notify.
What actually raises the price
The objective is not to make the attack impossible. It is to make your store more expensive than the next entry in the list, which against a campaign running over thousands of targets is generally sufficient.
Most published advice on credential stuffing assumes you control the login endpoint. On Shopify you do not. /account/login, /account and /account/recover are served by Shopify, and rate limiting, password policy and response shaping are Shopify's to set rather than yours. This is the same constraint documented in our fourth dispatch, and it is worth separating what you can change from what you cannot.
What Shopify controls, and you cannot tune
- Rate limiting on the account endpoints. Per-address limiting is the most effective control against stuffing, and on a Shopify storefront it is applied by Shopify. Merchants running authentication elsewhere should implement it themselves. Shopify merchants should know it exists, and that a sustained attack is worth reporting to Shopify support with timestamps.
- Password policy on hosted forms. Screening new passwords against a breach corpus is the correct defence against reuse, and Have I Been Pwned's range API does it free without transmitting the password. You cannot hook password creation on Shopify's hosted account forms, so this applies to any auth you run yourself.
- Recovery response wording. Shopify's password recovery already returns the same response whether or not the address exists, which is the right behaviour. Note that it does not close enumeration entirely: response timing leaks, and the registration form's "this email is already registered" message leaks more reliably still.
What you control
- Score the three account forms. Invisible scoring adds a per-attempt cost and catches operators running without a solver budget, which at the low-margin end is most of them. This is what our app does and it is not a complete answer on its own. It is also the mechanism the right-hand column of Figure 02 is modelling.
- Move to new customer accounts. Shopify's newer customer accounts use a one-time code sent by email rather than a reusable password. A credential stuffing campaign has nothing to stuff against a login that has no password, which makes this the only item here that removes the attack rather than pricing it. It does not remove the traffic, and there is a trade: a login that emails a code to any address typed into it is an email-sending endpoint open to strangers, which is precisely the amplifier described in our second dispatch. You are exchanging an account-takeover problem for a deliverability one. That is the better trade, but it is a trade.
- Watch the Customers list, not the login log. Clusters of accounts with no orders, no sessions and disposable-domain addresses, created inside a narrow window, are the visible signature. A Shopify Flow rule can tag them on creation and keep them out of your email platform before they reach a welcome flow.
- Do not step up on everyone. Where you do have a signal worth acting on, apply the extra check to the unusual case rather than the whole customer base. An operator paying tens of dollars for a million attempts is indifferent to friction costing a fraction of a cent. A customer trying to buy something is not.
Our third dispatch reached the same conclusion from the other direction. Every control in this category is a price, not a wall. The right-hand column of Figure 02 is what a price looks like when it works, and the three columns to its left are what the same campaign looks like against a store that never set one.
Spambuster builds form-spam protection for Shopify storefronts and sells scoring on the three account forms described above, which is a commercial interest in the conclusion of Figure 02. Tooling prices are quoted from Recorded Future's 2019 research and we have not re-verified them against current markets; we would expect them to have fallen, since most of the tools named are now distributed free, but we have not established that. Figures 01 and 02 are models built from published rates rather than measurements of any campaign. We have no first-party telemetry in this report, which is its main limitation. Corrections to contact@jola.com.au