Stop Credential Stuffing with Device and Login Signals

Credential stuffing uses stolen username and password pairs against your login API. Attackers try those pairs across accounts until one works. Track the campaign through user.login events.

Send customer id when you know it, plus device fingerprint, IP, session id, and whether the attempt succeeded. If you only send successful logins, you will miss the part of the attack that is loudest: the failures.

What stuffing looks like on the wire

Stuffing looks like many failures across identifiers, then a success on a new device. The passwords are real. The accounts are real. The device is not the one the customer used last week.

Write the rule as identifier, action, window, and threshold. Failures per IP in two minutes. Failures per device fingerprint in ten minutes. A success after a burst of failures on a quiet account. That sentence is what operations will read in the case file. "Suspicious login" is not a rule.

Pair IP reputation and VPN detection with device novelty. A VPN on a known-good phone is often travel. A VPN on a brand-new fingerprint after forty failures is stuffing. Do not BLOCK every new phone. Families buy phones. Travelers buy phones. REVIEW or step-up until a fingerprint or IP is listed.

If your stack is still an IP list, you will rotate with the attacker. Device fingerprints persist longer than addresses. That is the whole point of pairing velocity with device context, and it is why device intelligence versus IP-only checks matters on login, not only on payments.

MFA is not telemetry

Attackers prefer accounts that lack MFA. You still need the login event when MFA is on. Support has to explain a challenge. Risk has to see the failed attempts that came before it. Store the fraud event id next to the session so those two teams are looking at the same attempt.

A step-up is a product action. It is not a substitute for instrumentation. If you challenge the user and never send user.login, you cannot tell stuffing from a customer who forgot a password on a new handset.

Naiza evaluates login events with velocity rules and device intelligence, then returns ALLOW, REVIEW, or BLOCK with decision context. The event guide shows how to send customer, device, IP, and session identifiers.

Promote the rule the way you promote any other

Start the stuffing rule in shadow or REVIEW. Shared office networks and campus NATs will look busy. A flash of failed logins after a password-reset email can look like an attack. Sit with those cases for a week. List the fingerprints and IPs you have confirmed. Then enforce BLOCK on the high-confidence burst.

When you promote a shadow rule to enforcing, use the same contract as ALLOW, REVIEW, BLOCK without a black box: scoring can rank the queue; the named rule is what you defend.

Do not wait for a successful payout to notice the campaign. By then the password worked, the session is live, and the attacker is looking at the wallet. The login event is cheaper to hold than the withdrawal.

Stuffing is a login problem first. If you only score payouts, the attacker is already inside.