Subscription bombing and how to mitigate it

Original Article ↗ Hacker News Discussion ↗

Scope of the Problem & Attack Goals

  • Subscription/email bombing is described as cheap, commoditized (“as a service”), and often used to hide other actions (e.g., account takeover, card fraud, fake listings) or simply to harass.
  • Victims report hundreds to thousands of emails in hours, often from legitimate services (gov sites, e‑commerce, newsletters, support forms).
  • Some attacks appear to be pure inbox DoS with no obvious secondary fraud, which several commenters find puzzling.

Email Verification, UX Friction & Business Incentives

  • Many argue that not verifying email addresses is negligent, leading to privacy leaks (bank transfers, medical data, legal documents, court cases, mortgage info) to the wrong person.
  • Others note companies deliberately avoid verification to reduce friction and preserve impulsive purchases or easy signups.
  • Several call for regulation or even legal penalties for sending non‑verification emails to unverified addresses.
  • Suggested best practice: send only a single verification email, and no welcome/newsletter messages until verification and some meaningful user engagement.

Mitigations on Signup & Forms

  • Common defenses mentioned: CAPTCHAs/Turnstile, honeypot fields, simple math/image CAPTCHAs, inbound email checks, username/email entropy checks, LLM-based “gibberish” filters, and browser proof‑of‑work.
  • Honeypots and simple CAPTCHAs work against unsophisticated bots but can be bypassed; hidden fields may break accessibility or password managers.
  • Proof‑of‑work and rate limiting are seen as cheap and effective for some, but others say generic rate limiting and heuristic rules are hard to tune and maintain.

Cloudflare, Centralization & CAPTCHA Skepticism

  • Some see Cloudflare/Turnstile as pragmatic and effective, especially in “normal” (non‑invisible) mode.
  • Others strongly oppose relying on a single large provider, citing centralization, outages, privacy, and degraded UX (especially for VPN/Starlink/mobile users).
  • There is disagreement on how easily modern CAPTCHAs are bypassed; some point to paid CAPTCHA-solving services and advanced bots, others say big providers still block most low‑effort abuse.

Payment & Card‑Testing Abuse

  • A related pattern: attackers use “change credit card” flows and $1 authorization/refund checks to validate stolen card lists.
  • Suggested mitigations include: only allowing card changes on accounts with valid existing cards, limiting very small charges, stronger anomaly detection, “silent blocks” that fake declines, and processor‑level fraud controls.
  • Debate over where fraud detection should live: at the site vs. the payment processor; processors can detect patterns across merchants but also push risk and penalties back onto sites.

Alternatives & Radical Ideas

  • Proposed but controversial alternatives:
    • Reversing email flow (user initiates signup by sending an email).
    • Eliminating email from auth entirely or replacing it with RSS-style inboxes or third‑party identity providers.
  • Many point out such flows are unfamiliar, high‑friction, and likely to crush conversion, so adoption is unlikely.