A signup-abuse alert should lead to a decision, not a reflexive CAPTCHA for everyone.
Short answer: use CAPTCHA as a step-up control, and combine its result with device continuity and event-specific signals before accepting a registration. That keeps a clean session quick while making automated bursts expensive, and it gives the on-call engineer evidence to tune instead of a single opaque score.
The system I would operate has one hard boundary: the registration session owns the risk decision, while the CAPTCHA provider only supplies an assertion. A browser can pass a challenge and still be a scripted client replaying tokens, so the assertion needs a short lifetime, an audience check, and a server-side binding to the session and event.
Start with the page the alert sees
At 09:07 UTC, the page fired on a developer-tools conference opening registration. The on-call view showed 1,840 attempts in five minutes, 71% from newly observed device identifiers, and a sharp rise in registrations using the same /24 networks. Successful CAPTCHA assertions were still above 96%. That last number initially looked reassuring. It was not.
The useful signal was the gap between challenge success and completed-registration behavior: many sessions solved the challenge, fetched the form again, and submitted a different email within 12 seconds. The alert should have fired on that sequence earlier, before the queue filled with duplicate reservations.
This is an alert-to-action trace worth preserving in runbooks:
- Observe a burst by event, account, device, and network prefix.
- Correlate challenge completion with session age, token age, and form replay.
- Apply a step-up or hold decision, recording the reason and expiry.
- Measure false positives as abandoned legitimate registrations, not just blocked requests.
That fourth step matters. A threshold that catches every burst can also reject a campus or company NAT during the first minute of ticket release.
What should CAPTCHA, device, and event signals decide together?
CAPTCHA answers one narrow question: did a challenge service accept this interaction? It does not establish that the person is unique, that the browser stayed on the same session, or that the requested event allows another seat. Device signals add continuity: a rotating, privacy-aware identifier, browser characteristics, prior account history, and velocity. Event signals add context: remaining inventory, registration limits, release windows, and whether the email domain or account has already claimed a place.
Treat these as inputs to a policy with explicit outcomes. I use four: allow, challenge, hold for review, and deny. The policy should be deterministic enough to explain in an incident, even if the individual signals are probabilistic.
A minimal decision record might look like this:
type RegistrationSignals struct {
EventID string
SessionAgeSeconds int
CaptchaValid bool
CaptchaAgeSeconds int
DeviceSeen bool
AttemptsLastMinute int
EmailClaimsForEvent int
InventoryOpen bool
}
func decide(s RegistrationSignals) string {
if !s.InventoryOpen || s.EmailClaimsForEvent > 0 {
return "hold"
}
if !s.CaptchaValid || s.CaptchaAgeSeconds > 120 {
return "challenge"
}
if s.AttemptsLastMinute >= 8 && !s.DeviceSeen {
return "challenge"
}
if s.SessionAgeSeconds < 3 {
return "hold"
}
return "allow"
}
The numbers are policy examples, not universal defaults. Capacity planning should test them against the event's expected peak, challenge latency, and the registration service's SLO. If the write path has a 99.9% availability target, a synchronous reputation lookup in that path needs its own timeout and an explicit fail-open or fail-closed rule.
Work backwards from the signal you wish had fired
The first instrumentation change is to emit a stable decision event, not a log line assembled by each handler. Include event ID, session ID hash, device continuity state, challenge result, reason code, and policy version. Do not store raw challenge tokens or a fingerprint that can identify a person longer than the retention policy allows.
Then build a short funnel: form viewed, challenge issued, challenge accepted, registration attempted, reservation committed. A ratio such as accepted-challenge-to-commit by five-minute window catches replay and queue pressure. A second ratio, unique devices per account and account claims per event, catches shared automation without assuming an IP address is a person.
For the on-call, the dashboard needs a timeline and exemplars. Show the ten sessions that caused the alert, their reason codes, and whether a human reviewer released a hold. Aggregates alone hide the false-positive cost.
A test fixture should replay both hostile and ordinary traffic: a single household NAT registering four colleagues, a conference room of browsers behind one proxy, a scripted client with valid CAPTCHA assertions, and a user who pauses for ten minutes before submitting. The expected decision is part of the fixture.
Buy, build, or split the control plane
There is no universally correct ownership model. A managed challenge can reduce the cryptographic and abuse-detection code your team maintains; a self-hosted challenge can keep more data in your boundary but shifts patching and tuning into your on-call rotation. Splitting the decision policy from the challenge adapter is usually the least surprising design.
| Approach | Useful when | Trade-off to price into the plan |
|---|---|---|
| Managed CAPTCHA plus local policy | Small platform team, bursty public events | External dependency and data-processing review |
| Self-hosted challenge plus local policy | Strict network or data residency boundary | You own bot adaptation, updates, and capacity |
| Challenge only, no local signals | Low-value forms with little inventory pressure | Weak replay detection and poor incident evidence |
The catch is operational coupling. If challenge verification shares the same failure domain as registration writes, a provider timeout can become an event-wide outage or a blanket denial. Keep the adapter behind a narrow interface, set a budgeted timeout, and expose its outcome to the policy engine so the fallback is visible.
Stick with a simpler challenge when the event has no scarce inventory and the cost of an extra prompt is higher than the abuse. For high-demand releases, add device and event context, but do not silently turn a risk score into a permanent identity label.
Tune thresholds without punishing real attendees
Every rule needs a review window and a rollback path. Start with shadow evaluation: calculate the decision, record it, and do not block for one release cycle. Compare challenge rates, completion rates, duplicate claims, and reviewer reversals. Your mileage may vary; a developer conference with corporate SSO behaves differently from a public workshop with disposable email addresses.
I am not sure any single device signal will remain stable as browsers tighten privacy controls. That uncertainty is a reason to combine short-lived continuity with event limits, not a reason to collect more identifying data.
When the threshold is wrong, the damage is asymmetric. A missed bot burst consumes inventory and pages someone; an over-aggressive rule makes legitimate attendees retry until they abandon the form. Put both outcomes on the same SLO review, and require a human-readable reason code for every challenge, hold, or denial.
Top comments (0)