The Week 81 Bots Signed Up: Threat Modeling in Production

Threat models written in a document have a shelf life; threat models written by attackers arrive on their own schedule. Ours arrived as eighty-one new “users” with names like fLAgxsGzJcAcMldslI and Gmail addresses stuffed with dots — the classic signature of automated signup abuse.

The diagnosis mattered more than the cleanup. Dot-trick Gmail variants and harvested ISP addresses meant two overlapping attacks: signup-bonus farming against our promo credits, and list bombing — feeding strangers’ addresses into our registration form so our verification emails become someone else’s spam. The second one is the sneaky killer, because the real damage is to sender reputation: enough unwanted OTP mail and legitimate verification emails start landing in spam folders.

No single control stops this class of abuse, so we stacked them. Cloudflare Turnstile on registration, verified server-side so a headless client cannot skip the widget. Per-IP rate limits on registration, login, password reset, OTP resend, and promo validation — with durable enforcement below the edge, because in-memory counters reset every deploy. Credits withheld until email verification, which removed the entire economics of bonus farming. And purge tooling for never-verified accounts, so the residue does not accumulate.

Each layer fails differently, which is the point: a CAPTCHA-solving farm still hits rate limits; a slow drip past the rate limits still earns nothing without verified email; and everything leaves audit trail.

The lasting output was not the controls — it was the habit. Every new surface now gets an abuse review alongside its security review: what does this endpoint let a stranger make us do? Send email? Consume GPU time? Mint credits? An attacker’s creativity is bounded only by your side effects, and enumerating side effects is a much more honest threat-modeling exercise than enumerating attackers.