Credential Stuffing Through Mobile Carrier NAT
Meridian Credit Union's online banking login is protected by Cloudflare Enterprise. Between 08:00 and 09:30, /login and /oauth/token received 48,000 requests/min from 22,000 IPs; 74% of source IPs are in mobile carrier NAT ranges shared by thousands of users. The attack uses valid usernames from an old breach and rotates user agents and TLS fingerprints. IP-based rate limiting at 10 requests/min per IP already blocks 3% of legitimate mobile logins, causing complaints. The bank cannot add CAPTCHA to the native mobile app's token endpoint because the app has no web view. Peak legitimate traffic is 6,000 requests/min. The SOC wants to stop credential stuffing without locking out members. The bank has 2.3 million active mobile members.
1. Why is the existing IP rate limit failing, and what should the new rate-limit key be?
Read the worked answer
The IP key is wrong for this traffic. Mobile carrier NAT collapses thousands of members behind a small set of IPs, so a 10 requests/min per-IP limit punishes legitimate users while a distributed attacker with 22,000 IPs stays under the threshold per IP. Rotating user agents and TLS fingerprints also defeat simple reputation.
The rate-limit key should move toward the account or session, not the IP. If the username or account ID is exposed in a header or cookie, rate-limit /login and /oauth/token on that value, optionally combined with ASN or JA3/JA4. If the username exists only in the POST body, Cloudflare's edge rate limiting cannot see it reliably; enforce account-level lockout and velocity checks in the application or an edge Worker. Keep an IP limit as a coarse backstop but raise it well above the NAT norm, for example 100 requests/min, and alert rather than block at the first threshold.
2. Design a two-tier response: immediate edge controls and application changes.
Read the worked answer
Immediate edge controls: enable Bot Management scoring and block or challenge only the low-score web /login traffic; do not challenge the native /oauth/token endpoint. For the native API, require a valid client attestation or device-bound token before the request reaches the origin. Rate-limit /oauth/token by account header or cookie and by ASN, with a high IP backstop. Add a rule to block requests that reuse a breached username list if the list can be represented as a custom list.
Application changes: account lockout with exponential backoff, step-up MFA after suspicious velocity, device fingerprint binding, and breached-password checks. Return generic login errors to avoid username enumeration. Measure false positives by NAT ASN and by legitimate login success, and keep a kill switch to disable the new rules if member complaints spike.
3. How would you measure whether the response is working without hiding harm to legitimate members?
Read the worked answer
Track four signals: credential-stuffing success rate (successful logins from previously seen bad username/password pairs), blocked/challenged request volume by rule, legitimate login success rate by carrier ASN, and complaint volume. Compare the 08:00–09:30 window before and after the change. A drop in attack success with stable member success is the goal; a drop in both means the controls are too aggressive.
Also monitor challenge solve rates and 429 rates for NAT ranges. If a single carrier ASN shows a spike in 429s, the IP backstop is still too tight. Sample blocked requests to confirm they are attack traffic, not shared-IP members. Report the false-positive rate as a first-class metric, not just the blocked attack count.