Login abuse detection: see the network behind failed logins

Credential stuffing is thousands of login attempts that each look ordinary. FindIP Shield records login views, attempts and failures with the network behind them, including IPs reported in the FindIP malicious-IP feeds that cover credential stuffing and brute force, so the pattern is visible on the login form rather than in a log file a week later.

Try Shield on my login See an example

Free Preview · 10,000 events per site per day · No credit card · Terms apply

Malicious IP (credential stuffing, brute force) Hosting / datacenter Proxy Tor IP rotation in session

The problem

Account lockouts punish the victim. The attacker just rotates.

A lockout after five failures stops a naive script and locks out the real owner of a targeted account. A credential-stuffing run spreads its attempts across a proxy pool so each IP fails only once or twice.

What the attempts share is the network: hosting ranges, proxies, Tor, and IPs already reported in malicious-IP feeds for credential stuffing and brute force. That is visible per attempt, before any lockout logic runs.

Shield reports it on login_attempt and login_failed events, lets you add a Turnstile check to the login form for the risky cases only, and gives your server a way to verify the session before issuing a token.

What Shield shows you

The evidence, then the response you choose

Reputation on the attempt

login_view, login_attempt and login_failed events carry the risk score and reasons, including the malicious-IP signal backed by FindIP threat feeds that cover credential stuffing and brute force.

Rotation inside a session

A session whose IP or ASN changes between the login page and the submit is recorded with the reason. Combined with a hosting signal it is a strong indicator of automation.

A check before the token

Add a Turnstile challenge to the login form for high scores, and verify the session from your server with your secret key before you issue a session. The browser response is friction; the server check is the boundary.

Setup

Install on your login flow in three steps

For applications with their own login form. The npm package fits bundled apps; the script tag fits server-rendered pages. Pair either with the server verification endpoint.

Create a Shield site

Sign in, add the domain you control, and pick a privacy mode. You get a public site key; nothing connects until it is on a page.

Add the snippet

Paste one script tag before the closing body tag, or run npm install @findip/shield and call init() with your site key. Auto page and form tracking is on by default.

Watch the first real event

Submit a test on your own form. The event, its risk score and the reasons behind it appear on the site dashboard moments later.

Try Shield on my login Read the server verification guide

Prefer another route? Want the same reputation data in your backend directly? Use the IP reputation API.

Boundaries

What a risk score is, and what it is not

An assessment, not proof. A VPN, a hosting network or a changing IP is common for privacy-conscious and corporate users too. Shield explains the reasons so you can decide; it does not pass judgement on a person.

Friction, not a security boundary. Anything decided in the browser can be bypassed by someone who controls it. For decisions that matter, verify the session from your server with your secret key.

Unknown is never safe. Where no intelligence was available the status is unknown. Shield fails open: if a decision does not arrive, the form submits as normal.

Questions

Frequently asked

Never. The SDK derives form activity from form attributes and the submit event. Passwords, emails and usernames are not read or sent. If you want to attach the account after a successful login, pass a hashed user ID.

It can make the login form slower or challenged for risky networks, and it can tell your server not to trust a session. A determined attacker controls the browser, so the server-side verify call is the part that holds. Rate limiting and MFA remain yours.

Only if you configure a stop response for that reason, which we do not recommend. A Turnstile check for proxy or hosting networks keeps real users moving while adding cost for automation.

The malicious-IP categories come from the FindIP threat intelligence used by the lookup API and are updated continuously. A visitor with no intelligence available is reported as unknown, not safe.

Keep reading

Start by watching one real flow.

Create a free Shield site, install it, and look at the first real event before you decide on any response.

Try Shield on my login

Free Preview · Informational risk signals · You control enforcement