Updated 16 September 2026
01 · why the login form is the hard case
Why the login form is the hard case
Everywhere else on a site, a wrong decision is an inconvenience. On the login form it locks a paying customer out of their own account, and they will not try twice.
That asymmetry is what shapes the whole problem. A scraper can be refused on suspicion because the cost of being wrong is one missed page view. A person signing in cannot, which rules out the aggressive thresholds that would otherwise catch a stuffing run early.
Meanwhile the attack itself is unremarkable at the level of a single request. The address exists, the password is well-formed, the attempt fails, and a person who has forgotten which of their passwords they used here produces exactly the same record. The difference only appears across requests.
02 · where the difference shows
Where the difference shows
- 1 Distribution. One person fails a few times from one place. A stuffing run fails once each from a great many places, and the addresses share a provenance even when they share nothing else.
- 2 Timing. Human retries are irregular and get slower as the person thinks. Automated ones are regular, and stay regular.
- 3 What was loaded before the post. A person reached the form by loading the page it is on. A script usually posts to the endpoint directly, having loaded nothing.
- 4 The client underneath. A stuffing tool is an HTTP library wearing a browser’s user agent string, and the TLS handshake it opens is not the one that string implies.
03 · scanners and probing tools the catalogue names
Scanners and probing tools the catalogue names
| Bot | Operator | Default policy | Verifiable |
|---|---|---|---|
| AccessibleWebBot | Accessible Web | Allow | By user agent |
| Acunetix | Invicti Security | Challenge | By user agent |
| AITrustRadar | AI Trust Radar | Allow | By user agent |
| AliyunSecBot | Alibaba | Allow | By user agent |
| Arachnid Shield API | Canadian Centre for Child Protection | Allow | Signed requests |
| Black Duck Fast Dynamic | Black Duck | Allow | By user agent |
| BlackVeil-Security-Scanner | BlackVeil | Allow | By user agent |
| Blockaid | Blockaid | Allow | By user agent |
| Bushbaby | Cloudflare | Allow | By user agent |
| CensysInspect | Censys | Observe | By user agent |
| Cert Chief | Chief Tools | Allow | By user agent |
| CertChief | Chief | Allow | By user agent |
Read live from the Botscope crawler catalogue. Default policy is the catalogue default; every agent can be overridden per site.
04 · what this does not do
What this does not do
Botscope does not see passwords, does not know which accounts exist, and cannot tell a successful stuffing attempt from a legitimate sign-in on the strength of the request alone. It classifies the request, not the credential.
That means it belongs alongside the account-level defences rather than instead of them. Multi-factor authentication, breached-password checks at sign-up and rate limits per account are all doing something this cannot do, and the reverse is also true: none of them sees that the same client fingerprint is working through a list.
The named tools in the table above are the visible minority. Most stuffing traffic carries no name at all, which is why the signals in this page are about how a request was made rather than what it called itself.
Questions
Will a customer who forgot their password be blocked?
A handful of failures from one browser on one connection does not look like a stuffing run, and the graduated response asks for a check before it refuses anything. The decision, either way, is recorded against the request.
Does this replace multi-factor authentication?
No. MFA protects an account once a password is known to the attacker; this reduces how many passwords get tried in the first place. They address different halves of the same attack.
Can you tell me which accounts were targeted?
No. Botscope classifies requests and does not read the form body, so it can tell you a login endpoint is under an automated run and from where, but not which addresses were tried.
What about attempts spread out over weeks?
A slow run is harder to see by volume and still visible by client characteristics, because the same tooling produces the same handshake whatever pace it runs at.
Can I apply this to the login form only?
Yes. Policy is per path, so a stricter posture on authentication endpoints can sit alongside a lighter one on the public pages.
See which of these reach your site
Free plan, no card: 100,000 events a month with every feature on. Nothing is blocked until you turn enforcement on.