OrlandoJohansson7621

Posted on Sep 7

Layering CAPTCHA, Device, and Event Signals Against Registration Abuse (3 Recovery Rules)

#go #authentication #security

TL;DR

Layer CAPTCHA behind device and event risk signals, then keep account recovery on a stricter, separately measured path. A CAPTCHA result should change a decision; it should never be the decision by itself. For a media event registration system, that means allowing ordinary sign-ups, challenging uncertain traffic, and rejecting requests only when several independent signals agree.

The deciding constraint is recovery. An attacker who can reset an existing attendee's account can bypass controls applied only to new registrations, while an aggressive device rule can lock out a legitimate reader who changed phones before a sold-out event. Treat the registration, login, and recovery flows as related entry points into the same event inventory.

CAPTCHA is friction, not identity.

How should CAPTCHA, device, and event signals prevent registration abuse?

Start with three signal families and give each a narrow job. CAPTCHA estimates whether an interaction resembles human use. Device signals identify repeated behavior from a browser or device without asserting who owns it. Event signals describe the thing under attack: remaining capacity, sign-up velocity, repeated seat claims, release timing, and the value of a particular event.

The useful unit is a risk decision, not a CAPTCHA checkbox. A request can arrive with a valid challenge result and still be suspicious because one device is rotating email addresses against a high-demand premiere. Another request can have no stable device history and still be reasonable because the attendee followed an emailed recovery link, supplied a fresh authenticator, and isn't trying to reserve another seat.

Use an explicit action table so product, support, and security teams can review the policy without reverse-engineering code:

Combined evidence	Registration action	Recovery action
Low device velocity, ordinary event demand	Allow and record the decision	Continue with the normal recovery proof
New device or rising event velocity	Require CAPTCHA, then reassess	Require CAPTCHA plus an existing recovery factor
Reused device across many accounts and scarce inventory	Hold or reject the seat claim	Do not let CAPTCHA substitute for recovery proof
Missing or stale signals	Fail to a rate-limited review path	Preserve the account and escalate verification

This table deliberately has no universal score threshold. The weights depend on traffic shape, accessibility requirements, event scarcity, and the cost of a false positive. I'm not sure a threshold learned from free livestream registration would transfer to a limited in-person screening; a shadow-mode replay with labeled outcomes would resolve that question.

Keep the evidence independent where possible. IP address and inferred location often share the same network origin, so counting both as separate votes exaggerates confidence. Likewise, a cookie and a browser-derived identifier may disappear together in private browsing. Correlated signals can still help, but the decision record should say where they came from.

Make account recovery a separate risk path

OWASP recommends consistent authentication responses to reduce account enumeration and reauthentication after high-risk events. Those principles matter during event surges, when an attacker can test recovery identifiers at scale and the support team is under pressure to make exceptions. Return the same public response for known and unknown accounts, bound recovery artifacts to a single purpose and a short lifetime, and rate-limit attempts by more than one dimension.

Do not silently turn a successful CAPTCHA into proof of account ownership. The challenge only addresses automation risk. Recovery still needs an established factor or a carefully controlled replacement procedure, and a successful reset should invalidate the relevant sessions according to the application's session policy.

Three recovery rules keep the control understandable:

Never award or transfer an event reservation during recovery. Restore account access first; perform reservation changes through an authenticated action afterward.
Treat a new device plus a recovery attempt plus a high-demand event as a reason for stronger verification, not automatic rejection.
Record why the flow allowed, challenged, held, or denied the request, while excluding raw secrets and unnecessary fingerprint material from logs.

I've been paged by missed jobs and duplicate deliveries. The lesson carries over here: a decision and its side effect need different identities. Give every registration attempt an idempotency key, write the risk decision once, and make seat allocation consume that durable decision exactly once. A retry after a network timeout must return the existing result rather than create a second registration or spend capacity twice. This is where a long paragraph in the runbook earns its keep: state which component owns the idempotency record, how long it lives, what happens when the risk engine times out, whether a held seat expires, and which operator can release it. If those answers exist only in application code, the first high-traffic incident will turn into archaeology.

Implement a small, auditable decision core

Keep vendor responses at the edge and translate them into a compact internal model. The policy core should receive normalized facts, not an opaque vendor payload. That makes CAPTCHA providers replaceable, gives tests stable inputs, and prevents a provider-specific score from leaking through every service.

The following Go example uses intentionally simple thresholds. They are policy examples, not measured universal constants; tune them with your own labeled registration outcomes.

package risk

type Action string

const (
    Allow     Action = "allow"
    Challenge Action = "challenge"
    Hold      Action = "hold"
)

type Signals struct {
    CaptchaPassed       bool
    DeviceAccountCount  int
    DeviceAttempts10Min int
    EventFillPercent    int
    RecoveryFlow        bool
    RecoveryProofValid  bool
}

type Decision struct {
    Action  Action
    Reasons []string
}

func Decide(s Signals) Decision {
    // CAPTCHA never replaces an established account-recovery proof.
    if s.RecoveryFlow && !s.RecoveryProofValid {
        return Decision{Hold, []string{"recovery_proof_required"}}
    }

    highDeviceReuse := s.DeviceAccountCount >= 4 || s.DeviceAttempts10Min >= 8
    highEventPressure := s.EventFillPercent >= 90

    if highDeviceReuse && highEventPressure {
        return Decision{Hold, []string{"device_reuse", "event_pressure"}}
    }
    if highDeviceReuse || highEventPressure {
        if !s.CaptchaPassed {
            return Decision{Challenge, []string{"additional_evidence_required"}}
        }
    }

    return Decision{Allow, []string{"policy_satisfied"}}
}

In production, validate the CAPTCHA response server-side, enforce its intended action and freshness semantics, and make replay impossible under the provider's documented verification contract. Put a strict deadline around that verification. If a dependency is unavailable, a scarce-event registration should enter a bounded hold or retry state rather than defaulting to allow; an ordinary low-risk event may use a different policy. Write that choice down before launch.

Minimize device data. Prefer a rotating, pseudonymous identifier and coarse risk features over a permanent fingerprint assembled from every browser attribute available. Document retention, access, and deletion. Device evidence decays, so an old association should not condemn a device forever, particularly after an account recovery or legitimate device resale.

The catch is that device fingerprinting is not suitable as a sole control where shared devices, privacy tools, or accessibility software are common. Stick with account-bound authenticators and server-side velocity limits when the browser cannot provide stable device evidence. CAPTCHA also may not be suitable as the default gate for every attendee: it adds interaction cost, can create accessibility problems, and loses value once an attacker routes work through humans. Those are reasons to layer controls, not excuses to collect more data.

Choose CAPTCHA integration by failure boundary

Provider selection should follow the failure mode you can operate. Google reCAPTCHA offers challenge and score-oriented integration models; Cloudflare Turnstile supports widgets that can be used without placing the site behind Cloudflare; hCaptcha offers visible and invisible integration modes. Those differences affect how much client behavior enters the policy and what the fallback path must handle. They do not identify a universal winner.

Test at least three candidates against the same contract: server-side verification, replay resistance, action binding, latency budget, accessibility, regional behavior, privacy review, observability, and dependency failure handling. Also inspect data terms and current documentation directly. Product behavior and terms can change, and a comparison copied from an old blog post is not an operational control.

No CAPTCHA choice fixes weak recovery, missing idempotency, or unlimited attempts.

Verify, deploy, and roll back without guessing

Begin in shadow mode. Compute the proposed action but keep the existing user outcome, then compare decisions with confirmed abuse, support appeals, completed registrations, and recovery success. Segment the results by event type and flow. An aggregate false-positive rate can hide a severe problem for users on shared networks or for one accessibility path.

Before enforcement, run table-driven tests for boundary values and combinations. Include a valid CAPTCHA with abusive device reuse, a failed CAPTCHA with low event pressure, a new device in account recovery, concurrent retries using one idempotency key, and a nearly full event. Load tests should model bursts around ticket release rather than steady average traffic. Security tests should confirm that public recovery responses do not reveal whether an account exists.

Deploy policy versions independently of application releases. Log the policy version, action, coarse reason codes, event class, and a correlation identifier. Do not log CAPTCHA tokens, recovery secrets, raw browser fingerprints, or full IP addresses merely because they are convenient. Metrics should separate challenge presentation, challenge verification, policy decision, registration commit, duplicate suppression, hold expiry, recovery completion, and support reversal.

Rollback means selecting the prior policy version, not deleting evidence or bypassing all controls. Preserve rate limits and idempotency during rollback. If challenge completion drops sharply, first disable the rule that requires the challenge for the affected cohort; keep high-confidence multi-signal holds in place and watch reservation integrity. A kill switch that turns every request into allow is easy to operate and hard to defend.

The final launch review is short: recovery never grants a reservation, CAPTCHA never proves ownership, two correlated browser observations do not count as two independent signals, and every seat-changing operation is idempotent. If the dashboard cannot demonstrate those properties, the system isn't ready for a high-demand event.

DEV Community