TL;DR: credential stuffing detection in-session versus post-login
- Rate limiting by IP was the industry playbook, but modern attacks spread 50,000 login attempts across 50,000 residential IPs, so your logs see one request per address and every alerting rule stays silent.
- Stolen credentials drive 39% of breaches in Verizon's 2026 DBIR; cside's device fingerprint stays stable across incognito, VPN, and cookie-clearing across more than 100 browser signals, so cross-account correlation surfaces the attacker's infrastructure that IP rotation was meant to hide.
- Before the next fraud review, ask whether your login stack fires on cross-account device reuse, TLS handshake fingerprint mismatch, and mechanical form-fill cadence, or only on IP thresholds attackers stopped triggering years ago.
Credential stuffing is hard to catch because attackers now spread stolen-password login attempts across tens of thousands of rotating residential IPs, so per-IP rate limiting sees each address only once. The signals that still work are the ones an attacker cannot cheaply rotate: the device behind the requests and how the session behaves.
Three of those signals reliably reveal credential stuffing. The first is cross-account device fingerprint correlation, where the same device identifier appears across login attempts on different accounts within a short window. The second is a new device on a known account, where a registered account logs in from a device fingerprint it has never used before. The third is a network context anomaly, where a VPN or proxy connection shows up on a session that previously always came from a residential IP. All three identify the attacker's infrastructure and behavior no matter how many IP addresses they cycle through.
Why per-IP rate limiting misses most credential stuffing today
Per-IP rate limiting was an effective credential stuffing defense when attacks came from a small number of servers. That era has passed.
Modern credential stuffing operations use residential proxy networks that rotate IP addresses on every request. An attacker running 50,000 login attempts spreads them across 50,000 different residential IP addresses. Your rate limiter sees each IP exactly once and takes no action, because a single login attempt from any given IP is indistinguishable from normal traffic.
The attack lands. The accounts are compromised. The only evidence in your server logs is a marginally elevated login attempt count with a geographic distribution that mimics organic user behavior.
Detection requires moving to signals the attacker cannot cheaply rotate. Stolen credentials are involved in 39% of all data breaches (Verizon Data Breach Investigations Report 2026), so stopping them at the login layer before damage is done means relying on signals that persist across IP rotation.
Signal 1: cross-account device fingerprint correlation
A device fingerprint is a stable identifier derived from browser signals: canvas entropy, font rendering characteristics, WebGL output, audio context, timing patterns, and headless browser flags. Unlike an IP address, a device fingerprint cannot be changed by connecting to a different proxy. The attacker's browser environment stays consistent across requests.
When device ID X attempts login on accounts A, B, C, D, and E within a 30-minute window, that is a credential stuffing attack. Each individual attempt may look legitimate on its own: correct password format, matching geolocation, reasonable timing. The cross-account correlation reveals that a single piece of infrastructure is behind all five attempts.
This is the signal per-IP detection misses entirely. The attacker rotates IPs. The device fingerprint stays the same.
To implement it, log the device fingerprint alongside every login attempt, then query across attempts to identify device IDs that appear on more than a threshold number of distinct accounts within a time window. A single device touching more than three distinct accounts in an hour is a high-confidence signal. A single device touching ten accounts in thirty minutes is close to certain.
Signal 2: a new device on a known account
A new, unrecognized device fingerprint attempting login on a long-established account is a high-risk signal even when the correct password is entered. An account that has always authenticated from the same device fingerprint carries an implicit expectation: future logins will come from that fingerprint or one with a strong similarity score.
When device ID 456 attempts login on an account that has exclusively used device ID 123 for two years, treat it as high-risk even if the password is right. The probability that the legitimate user has switched to a completely new browser environment at the exact moment an attacker also holds their password is low.
The signal gets significantly stronger when combined with network context. A new unfamiliar device attempting login with a data center VPN active, on an account that has only ever connected from residential IPs, is the single strongest individual indicator of a targeted account takeover via credential stuffing.
This detection requires per-account device history. Log the device fingerprint on every successful authentication. When a new fingerprint appears on a high-value or long-established account, flag it for step-up authentication or block it pending verification.
Device fingerprints need to stay stable across the scenarios attackers use to obscure their identity. cside's fingerprint holds up with high accuracy across incognito mode, VPN connections, and cookie-clearing, derived from more than 100 browser signals per session. An attacker who clears cookies and connects through a VPN is still producing the same device fingerprint.
Signal 3: network context plus session cadence
Combining VPN and proxy detection with scripted session cadence produces the highest-confidence credential stuffing verdict, because both signals are independently difficult to fake and together are near-conclusive.
Residential proxy networks let attackers rotate through real home IP addresses to evade geographic and IP reputation filtering. The connection characteristics of a residential proxy request still differ from a genuine residential connection. TLS handshake fingerprint TLS fingerprinting analyzes the TLS handshake parameters, including cipher suite order and extension presence, to distinguish proxy-relayed connections from direct residential ones.
An account that has connected from a genuine residential UK IP address for three years, then suddenly shows a TLS fingerprint consistent with proxy relay, is a network context anomaly. On its own, that warrants attention. Combined with scripted session cadence, it is near-certain evidence of an automated attack.
Scripted credential stuffing produces login attempts at either inhumanly fast speeds or mechanically even intervals. A human types their credentials with natural variation in inter-keystroke timing, pauses between fields, and irregular form interaction. A script fills fields instantaneously or at precisely timed intervals. cside measures this cadence as part of its session evaluation.
A session showing proxy-consistent TLS characteristics and mechanical form-fill cadence, on an account with no proxy connection history, is a credential stuffing attempt with very high confidence.
How cside returns these signals
cside evaluates every session and returns a real-time verdict whose values map directly to the three detection signals above.
It returns a stable device fingerprint identifier. Log it on every login attempt, then query it across attempts to find cross-account correlation (Signal 1) and against per-account history to spot a new unfamiliar device (Signal 2).
It returns a VPN and proxy flag, set when the session connects through a VPN, data center proxy, or residential proxy relay detected via TLS handshake fingerprint TLS fingerprinting. Combine it with account history to identify network context anomalies (Signal 3).
It returns a session cadence score that quantifies how closely the session's interaction timing matches human patterns. A low cadence score together with an active proxy flag maps straight to the third signal.
Combining these values lets you catch credential stuffing attacks that would be invisible to per-IP rate limiting, a bot score alone, or any single-signal approach.
Detection versus prevention
Detection tells you a credential stuffing attack is in progress. Prevention stops it from succeeding.
Once you have identified an active attack using the three signals above, you have several options: block the device fingerprint from further login attempts, require step-up authentication for affected accounts, invalidate any sessions established during the attack window, and alert affected users to reset their passwords.
The detection signals described here are the inputs. Your application logic, fraud orchestration layer, or WAF determines the response.
For a complete approach to stopping credential stuffing once detected, see cside's guide to understanding and stopping credential stuffing attacks, the device fingerprinting solutions page for how these signals integrate into a full stack, and the account takeover use case for where they fit in an ATO defense.
