Bot Defense, Fraud & Account-Takeover Prevention

Intent hiding inside legitimate-looking traffic

DDoS is about volume. This lesson is about intent hiding inside legitimate-looking traffic: an attacker doing exactly what a real user does, just automated and at scale. Rate limits alone will not catch it because each individual request looks fine.

Credential stuffing and account takeover

Attackers take username/password pairs leaked from other breaches (billions are public) and replay them against your login, because people reuse passwords. A few percent succeed. Defenses stack:

• Breached-password checks at login and signup (check against a corpus like Have I Been Pwned's k-anonymity API) so a known-leaked password is rejected or force-reset.
• MFA, ideally phishing-resistant (WebAuthn/passkeys, TOTP over SMS). This is the single highest-leverage control against ATO.
• Velocity and impossible-travel checks. Track login attempts per account, per IP, and per device. "Failed logins across 5000 accounts from one IP in a minute" is stuffing. "Login from New York, then London 20 minutes later" is impossible travel and a hijack signal.

Bot management, Sybil, and card testing

Bot management is detecting automation itself. Signals: device fingerprinting (TLS/JA3 fingerprint, browser and header entropy, canvas fingerprint), behavioral signals (mouse movement, typing cadence, time-on-form, since bots fill a form in 50 ms), and invisible challenges that run before you ever show a CAPTCHA. These feed a risk score, not a binary verdict.

Fake-account / Sybil defense. One attacker creating thousands of accounts to farm signup bonuses, post spam, or launder fraud. You cannot stop account creation, so you raise its cost and reduce its value: phone/email verification (a phone number costs more to acquire than an email), per-identity and per-device velocity limits (N accounts per device per day), reputation and aging (new accounts have limited privileges until they build trust), and rejecting disposable-email and VOIP-number ranges.

Card testing on checkout: fraudsters validate stolen card numbers by running many tiny authorizations. Defend with velocity limits per card/BIN/device, 3-D Secure step-up, and blocking the classic "many $1 auths, high decline rate" pattern.

Graduated, risk-based response

The unifying idea is that every event gets a risk score from a pipeline of features + rules + ML. Low risk passes silently. Medium risk triggers step-up auth (MFA challenge, email verification, 3DS). High risk gets blocked or sent to a manual-review queue. Make every action auditable and reversible (you will have false positives and must be able to unblock a real user fast) and build a feedback loop so confirmed fraud and confirmed false positives retrain the model.

Interview nuance: the tradeoff to name explicitly is friction versus conversion. A hard block on anything suspicious kills signups and revenue and generates support tickets from real users. The senior move is graduated friction: invisible checks for the 95% who are clearly fine, a light challenge for the ambiguous middle, hard action only for high-confidence abuse. State the metric: you are optimizing fraud caught per unit of legitimate-user friction, not fraud caught in isolation.

Recap: layer breached-password checks, MFA, and velocity/impossible-travel against credential stuffing and ATO; use fingerprinting, behavioral signals, and invisible challenges for bots; raise cost and lower value (phone verification, per-device limits, reputation) against Sybil/fake accounts; score every event with features+rules+ML and respond with graduated, auditable, reversible step-up friction instead of blunt blocks.