ATO detection IDs: naming the attack session instead of chasing addresses
Addresses were never the identity of an attack
Residential proxy rotation killed address based defence years ago, but many rule sets still act as if an IP address names an attacker. In a modern stuffing run each attempt can arrive from a fresh address in the right country, sometimes a real household connection rented through a proxy network. Blocking addresses one by one is mowing: the list grows, the attack continues, and legitimate shoppers sharing those addresses collect the damage.
What stays stable across a campaign is behaviour: the order of requests, the timing between them, the password patterns being tried, the failure rhythm. A detection ID that groups attempts by that shared behaviour names the thing you actually want to stop. When the label is per customer, it also respects that the same tooling aimed at a bank and at a shoe store produces different traffic, and the defence can learn each shape separately.
Per customer detection beats a global list
Global blocklists answer yesterday's attack on somebody else's site. Per customer anomaly detection watches your own login baseline: your normal ratio of failures to successes, your usual geography, your peak hours. A campaign against your store bends those lines in specific ways, and a system trained on your traffic notices the bend earlier than a shared list notices a new address range.
The practical payoff is in the dashboard. Instead of a fog of blocked addresses, the team sees one labelled incident: attempts counted, accounts targeted, success rate, start time. That shape supports a decision. You can step up challenges for the labelled traffic only, leave ordinary shoppers untouched, and watch the success rate fall. Incident shaped data turns bot defence from a settings page into an operational habit.
Hashed user IDs close the privacy gap
Tracking which accounts are being attacked usually means logging usernames in yet another system, which creates its own risk. Hashed per domain user identifiers solve that neatly: the username is cryptographically hashed into an identifier that is consistent for your site, so patterns per account are visible, while the raw credential list an attacker would love to steal never accumulates in your analytics.
With that in place, the slow attacks become visible. An account receiving three careful attempts a day for a month never trips an endpoint alarm, but its hashed ID accumulates a history no honest login pattern produces. Pair that history with a leaked credential flag on any successful login for the account, and you have the two signals that justify a quiet forced reset before the attacker ever gets in.
Decide the playbook before the first incident arrives. Ours, in plain terms: challenge all traffic carrying the label, tighten login rate limits per account for the duration, force resets only for accounts where a flagged attempt succeeded, and message those account holders in plain language about what happened. Mass resets for every targeted account punish thousands of shoppers for attempts that failed, and teach them to ignore your security mail.
What to do with a labelled incident
Afterwards, keep the label's data. Attack tooling gets reused across stores and across months, and a returning campaign recognised in its first hour is a very different event from a new one discovered in its third day. The detection ID is memory. Stores that clear incident data after each event agree to be surprised by the same attacker on a regular schedule.
Frequently asked questions
Keep reading: Residential proxy networks: why the worst bot traffic has a home address, Mobile API abuse: the bot traffic your web defences never see.
Frequently asked questions
What is an account takeover detection ID?
It is a label a bot management system attaches to login traffic matching an account takeover pattern for your specific site. Instead of listing addresses, which rotate constantly, the label groups attempts by shared behaviour so they can be challenged or blocked as one campaign. Cloudflare reports billions of suspicious login attempts caught this way daily across its network.
Why does per customer detection catch attacks a blocklist misses?
A blocklist knows addresses and tools seen elsewhere. Per customer detection knows your own login baseline: failure ratios, geography, timing, and account targeting patterns. A campaign bends those baselines in recognisable ways, often before its addresses appear on any shared list, so the anomaly shows up earlier and with fewer false positives.
Are hashed user IDs safe to store in analytics?
They are designed for exactly that. The identifier is a cryptographic hash of the username scoped to your domain, so it is stable enough to track attempts against one account over time but does not expose the username itself. That avoids building a fresh list of customer identifiers inside a logging system.
Should every targeted account get a forced password reset?
No. Force resets where a flagged attempt actually succeeded, and step up challenges for the rest. Resetting thousands of accounts over failed attempts creates support load and trains customers to ignore security notices. The targeted accounts with no successful flagged login need watching, not disruption.