Design Bot Defense & Sybil-Resistant Registration Architecture

1. Problem Statement & Scope Clarification

System Mission

Design a multi-tiered, enterprise-grade bot defense and Sybil-resistant account registration architecture capable of protecting global platforms from coordinated bot attacks, automated credential stuffing, ticket scalping, fake account farm creation, and distributed scrapers. The platform must absorb volumetric registration floods ($100,000+$ malicious requests/sec), enforce sub-100ms edge filtering via AWS WAF Bot Control and JA4/JA3 TLS fingerprinting, impose computational economic asymmetry on adversaries via dynamic Client-Side Proof-of-Work (Hashcash) puzzles, and validate account authenticity with zero friction for legitimate human users.

Synthesizing vector architecture diagram...

Functional Requirements

1. Multi-Tier Edge Traffic Classification: Inspect inbound HTTP/2 and HTTP/3 TLS handshakes; compute JA4/JA3 fingerprints, analyze TCP window sizes and header ordering, and match against threat intelligence feeds to assign a real-time Risk Score ($0 - 100$).
2. Client-Side Proof-of-Work (Hashcash) Challenge: Dynamically generate cryptographic puzzles with variable difficulty ($D = 16 - 24\text{ bits}$ of leading zeros) based on client risk scores. Legitimate users solve the puzzle in $< 500\text{ ms}$; botnets attempting $10,000$ registrations/min face catastrophic CPU exhaustion.
3. Disposable Domain & Carrier Screening: Screen registration emails against a high-performance in-memory Bloom Filter containing $> 100,000$ disposable/temporary email domains; detect and reject VoIP/virtual phone numbers via carrier lookup APIs.
4. Honeypot & Canary Traps: Inject invisible form fields and fake API endpoints into registration workflows. Automated DOM scrapers and headless browsers filling honeypot fields are fingerprinted and blacklisted immediately.
5. Sybil Device Fingerprint Registry: Generate deterministic hardware/browser fingerprints (combining WebGL entropy, Canvas 2D render hashes, AudioContext curves, and CPU concurrency) stored in Amazon DynamoDB to prevent one device from creating multiple accounts.

Non-Functional Requirements (SLAs & SLOs)

• Edge Decision Latency: $P50 < 5\text{ ms}$, $P95 < 15\text{ ms}$, $P99 < 30\text{ ms}$ processing overhead added by edge WAF and Lambda@Edge inspection.
• Server PoW Verification Latency: $P99 < 1.0\text{ ms}$ ($O(1)$ single SHA-256 hash evaluation).
• False-Positive Rate (FPR): Strict $< 0.01\%$ false-positive block rate for human users on clean residential IPs.
• Volumetric Attack Absorption: Sustain $100,000\text{ malicious req/sec}$ attack bursts at the edge without degrading origin authentication databases.
• Data Durability & Isolation: 11 Nines ($99.999999999\%$) for user account credentials; encrypted at rest via AWS KMS.
• CAP / PACELC Classification:
  • Edge Rate Limiting & Bot Scoring: AP / PA/EL system. Fast edge admission decisions prioritize low latency over cross-region rate-limit consistency.
  • Account Registration & Credential Store: CP / PC/EC system enforcing strict unique constraints on email, username, and device hashes in Amazon DynamoDB.

Out-of-Scope

• Biometric facial recognition or government identity card verification (KYC/AML).
• Continuous in-session behavioural fraud scoring during financial wire transfers (handled by dedicated Fraud Services).
• Post-registration account recovery social graph verification.

---

2. Capacity & Scale Estimation (Back-of-the-Envelope Math)

Traffic Scale Calculations

• Global User Registrations (Nominal): $10,000,000$ human registrations/month. $\text{Average Human Registrations} = \frac{10,000,000}{30 \times 86,400\text{ s}} \approx 3.85\text{ registrations/sec}$ $\text{Peak Legitimate Human Ingress} = \mathbf{50\text{ registrations/sec}}$
• Volumetric Adversary Attack Surge (Credential Stuffing / Scalper Bot Farm): Botnets utilizing $500,000$ rotating residential proxy IPs attempting simultaneous signups during a viral drop: $\text{Peak Malicious Bot Ingress} = \mathbf{100,000\text{ requests/sec (Edge Level)}}$ $\text{Origin Target Capacity (Filtered by Edge)} = \mathbf{\le 500\text{ valid requests/sec (99.5\% dropped at edge)}}$

Proof-of-Work (Hashcash) Computational Asymmetry Math

• Target Difficulty ($D = 20\text{ bits}$ of leading zeros): $\text{Expected Hash Operations to Solve} = 2^{20} = 1,048,576\text{ SHA-256 evaluations}$
• Client Computation Time (Modern JavaScript / WebAssembly client executing $2\text{M hashes/sec}$): $\text{Client Compute Time} = \frac{1,048,576}{2,000,000} \approx \mathbf{0.524\text{ seconds}}$
• Server Verification Time (Single SHA-256 evaluation): $\text{Server Verification Time} = 1\text{ hash evaluation} \approx \mathbf{0.000002\text{ seconds (2 }\mu\text{s)}}$
• Computational Asymmetry Ratio: $\text{Asymmetry Factor} = \frac{1,048,576}{1} \approx \mathbf{1,000,000 : 1\text{ advantage to defender}}$
• Adversary Attack Cost (be honest about it): A botnet attempting $100,000\text{ requests/sec}$ must solve $100,000 \times 1,048,576 \approx 1.05 \times 10^{11}\text{ hashes/sec}$. In browser JavaScript (~2 MH/s per core) that is ~50,000 cores, but an attacker does not use a browser: native SHA-NI code reaches ~50 MH/s per core (~2,000 cores) and a single commodity GPU ~1-2 GH/s, so ~50-100 GPUs (tens of dollars per hour on a cloud) sustain the full flood. Proof-of-Work therefore raises the marginal cost of a fake account by orders of magnitude and throttles residential-proxy botnets (whose IoT/router hosts have no GPU), but it does not make farming impossible. That is why it is one rung of the escalation ladder in §6.3, feeding JA4 clustering, subnet velocity and device-registry limits, never the whole defense.

Storage & In-Memory Sizing

• Bloom Filter for Disposable Email Domains:
  • Item count ($N$): $100,000$ disposable domains (e.g., tempmail.com, guerrillamail.com).
  • Target false-positive probability ($P$): $0.01$ ($1\%$).
  • Required bits ($M$): $M = -\frac{N \times \ln(P)}{(\ln 2)^2} = -\frac{100,000 \times \ln(0.01)}{(0.69315)^2} \approx 958,506\text{ bits} \approx \mathbf{117\text{ KB RAM}}$ (Fits entirely within L3 CPU cache; near-zero latency lookup).
• Redis Sliding Log Rate Limiting: Tracking IP subnets (/24) and device fingerprints over a 10-minute rolling window: $10,000,000\text{ active IP entries} \times 64\text{ bytes} \approx \mathbf{640\text{ MB RAM}}$.
• DynamoDB User & Device Fingerprint Registry (3-Year Horizon): $50\text{M users} \times 1.5\text{ KB record} = \mathbf{75\text{ GB storage}}$ (replicated across Multi-AZ).

---

3. AWS-First High-Level Architecture

Synthesizing vector architecture diagram...

Follow a sign-up from the top. In "Tier 1: Edge TLS & WAF Inspection", WAF bot rules run first, then the edge scores the request from 0 to 100 using its TLS fingerprint (JA4), whether it comes from a datacenter, Tor or a proxy network, and whether the honeypot field was filled. In "Tier 2: Proof-of-Work Challenge Engine", the score picks a path: 80 or more is blocked, 30-79 must solve a SHA-256 puzzle and resubmit, and under 30 passes straight through. In "Tier 3: Stateful Auth & Sybil Validation", the registration service checks disposable email domains with a Bloom filter, looks for many accounts from the same device fingerprint, and enforces sliding-window rate limits in Redis before writing to DynamoDB. The friction grows with suspicion, so real users usually never see a challenge.

Data Flow Walkthrough

1. Edge TLS & Network Handshake Inspection (Tier 1):
   • When a client establishes a TLS 1.3 connection to Amazon CloudFront, CloudFront terminates TLS and exposes the handshake fingerprint as the CloudFront-Viewer-JA3-Fingerprint / CloudFront-Viewer-JA4-Fingerprint headers; AWS WAF has native JA3/JA4 match statements. Lambda@Edge never sees the raw Client Hello, it consumes those headers.
   • The JA4 fingerprint (cipher suites, ALPN protocols, TLS extensions, elliptic curves) is the primary transport signal at the edge; HTTP/2 frame fingerprints (SETTINGS ordering, header order) are only available where the platform terminates HTTP/2 itself (see the caveat in §6.2).
   • The IP address is cross-referenced against AWS WAF Bot Control and MaxMind GeoIP databases to identify datacenter hosting providers (AWS, GCP, DigitalOcean, Hetzner), known Tor exit nodes, and commercial VPNs.
2. Honeypot & Canary Trapping:
   • Hidden CSS/DOM form inputs (e.g., <input type="text" name="b_address_zip_code" style="display:none" tabindex="-1">) are delivered in the HTML.
   • Legitimate humans do not interact with hidden fields. Automated headless bots (Puppeteer, Playwright, Selenium) auto-fill every input field. If the honeypot field is populated, the request is flagged with Risk Score 100.
3. Adaptive Challenge Dispatch (Tier 2):
   • Risk Score $< 30$ (Human): The request proceeds directly to the registration endpoint without user disruption.
   • Risk Score $30 - 79$ (Suspicious / Datacenter / High Velocity): The edge rejects direct form submission and responds with an HTTP 428 Precondition Required containing a Proof-of-Work Challenge (seed, difficulty, expiration_epoch, hmac_signature).
   • The client browser executes WebAssembly/WebWorker hash iterations to find the valid nonce.
4. Stateful Identity & Disposable Domain Screening (Tier 3):
   • Once submitted, the Auth & Registration Service re-validates the PoW solution in $2\text{ }\mu\text{s}$ using a single SHA-256 hash (defense in depth: the edge already verified it and consumed the seed, so a request that reaches origin with a bad nonce indicates an edge bypass and is logged as such).
   • The user's email domain is checked against an in-memory Bloom Filter of $100,000+$ disposable temporary email services.
   • The client device fingerprint (combining Canvas render hash, WebGL vendor, and AudioContext phase curves) is checked in Amazon DynamoDB. If the fingerprint has registered $> 2$ accounts in the past 30 days, registration is blocked.
   • The credential record commits atomically to DynamoDB via TransactWriteItems: the USER# item, an EMAIL#<email> uniqueness item with attribute_not_exists(PK), and the DEVICE#/USER# association. A GSI on email cannot enforce uniqueness, so the dedicated EMAIL# item is what makes two concurrent signups with the same address impossible.

---

End-to-End Request Tracing Walkthrough

---

4. API Interface Design & Wire Protocol

1. Request Proof-of-Work Challenge (POST /v1/auth/challenge/pow)

httpCopy
POST /v1/auth/challenge/pow HTTP/2
Host: auth.platform.com
Content-Type: application/json
X-Device-Fingerprint: 8f92a102938471bce0918234
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36...

{
  "action": "ACCOUNT_REGISTRATION",
  "client_timestamp_epoch_ms": 1773648000000
}

Response: 200 OK(Puzzle Payload)

jsonCopy
{
  "challenge_id": "pow_01HZX894KMNPQ9283",
  "seed": "7f8a9b2c-3d4e-5f6a-7b8c-9d0e1f2a3b4c",
  "difficulty_bits": 20,
  "algorithm": "SHA-256",
  "expires_at_epoch_ms": 1773648180000,
  "signature": "c8f92b40192a83e...hmac_signature"
}

---

2. Submit Registration with Proof-of-Work Solution (POST /v1/auth/register)

httpCopy
POST /v1/auth/register HTTP/2
Host: auth.platform.com
Content-Type: application/json
X-PoW-Challenge-Id: pow_01HZX894KMNPQ9283
X-PoW-Nonce: 8492019
X-PoW-Signature: c8f92b40192a83e...hmac_signature
X-Device-Fingerprint: 8f92a102938471bce0918234
Idempotency-Key: 9a8b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d

{
  "email": "sarah.connor@gmail.com",
  "password": "<plaintext over TLS; the server derives the Argon2id hash - a client-side hash would itself become the password>",
  "username": "sarah_c_2026",
  "honeypot_field_company": "", 
  "device_telemetry": {
    "canvas_hash": "a8f9021b",
    "webgl_vendor": "Apple Inc.",
    "screen_resolution": "2560x1440",
    "touch_support": false
  }
}

Response: 201 Created

jsonCopy
{
  "user_id": "usr_981402819284",
  "email": "sarah.connor@gmail.com",
  "status": "ACTIVE",
  "auth_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
  "created_at_epoch_ms": 1773648001200
}

---

3. Status Codes & Error Contracts

---

5. Data Models & Storage Architecture

DynamoDB Single-Table Design: Users & Sybil Device Registry

Stores user credentials, device fingerprints, and account association mappings in Amazon DynamoDB.

Synthesizing vector architecture diagram...

Three item types share one DynamoDB table. USER items (PK USER#id) hold account data; DEVICE_FINGERPRINT items (PK DEVICE#hash) hold per-device counters such as total_accounts_created and a blacklist flag. DEVICE_ASSOCIATION items link the two: stored under the device's partition with the user in the sort key, so reading DEVICE#hash returns every account ever created from that device in one query, which is the direct signal of one device making many accounts. The GSI flips the key (GSI1PK USER#id), so the reverse question, which devices has this user used, is also one query. Designing both lookups into the keys means the fraud check at sign-up costs a single read instead of a scan.

DynamoDB Single-Table Schema Layout

---

Redis Sliding Window Rate Limiter Lua Script

Enforces strict rate limits per IP subnet (/24) and per device fingerprint over a sliding 10-minute window.

luaCopy
-- KEYS[1]: rate_limit_key = "rate:reg:subnet:{ip_subnet_24}"
-- ARGV[1]: current_epoch_ms
-- ARGV[2]: window_size_ms (e.g., 600000 for 10 minutes)
-- ARGV[3]: max_allowed_requests (e.g., 10 signups per /24 subnet per 10m)

local current_time = tonumber(ARGV[1])
local window_start = current_time - tonumber(ARGV[2])
local max_limit = tonumber(ARGV[3])

-- 1. Remove all events older than the 10-minute sliding window
redis.call('ZREMRANGEBYSCORE', KEYS[1], 0, window_start)

-- 2. Count active entries remaining in the sliding window
local current_count = redis.call('ZCARD', KEYS[1])

if current_count >= max_limit then
    return 0 -- RATE LIMITED: SUB-NET LIMIT EXCEEDED
end

-- 3. Add current timestamp to sorted set
redis.call('ZADD', KEYS[1], current_time, current_time)
redis.call('PEXPIRE', KEYS[1], ARGV[2])

return 1 -- ALLOWED: RATE UNDER LIMIT

---