Every account obeyed the limit; the attack still worked
In a hypothetical trial service, each account receives a useful compute allowance. Every account stays below its limit. One operator creates thousands of accounts and consumes the entire fleet.
The limiter enforced a scarce budget per identity. Identity was not scarce.
Price the attack without inventing a benchmark
Let be expected extractable value per successful account, the cost of an attempt, and the probability of a valuable successful account. Expected margin per attempt is approximately , before other costs and risks. These are variables to estimate, not vendor prices or a permanent economic guarantee.
Raising account-creation cost above the trial's immediate value can discourage profit-seeking abuse. Does it eliminate all abuse? What happens to legitimate users?
Keep valuable actions behind verified, meaningful conditions if the product allows it. Account creation, email sending, expensive API calls, reward grants, and withdrawals need separate budgets and durable uniqueness. Do not invent new product reward amounts from a teaching example.
Cheap signals should remain signals
A honeypot field can catch scripts that fill every input, but autofill, password managers, and assistive workflows can also populate it. Keep the trap out of ordinary keyboard and accessibility paths, test real form tools, and prefer a measured step-up response over irreversible rejection based on one field. A canary endpoint can signal unexpected automation; first account for legitimate crawlers and monitoring.
Time-to-submit is similarly ambiguous. A fast submission may use a password manager; a slow bot can wait. Preserve reasons and outcome feedback so the rule can be evaluated instead of accumulating folklore.
An email address is not a person
Parse and normalize the domain using a well-defined IDNA/domain policy. Do not blindly lowercase or rewrite every local part or strip plus/dot aliases across all providers; those equivalences are provider-specific. An MX/domain check establishes limited routing evidence, not control of the mailbox. Verification proves access at that moment, not a unique human.
Disposable-domain lists age quickly and can block legitimate privacy-conscious users. A Bloom prefilter can avoid exact lookups on likely nonmembers, but a possible match must be checked before an adverse decision. Build a new exact list/filter generation, validate it, then swap atomically. Record list provenance, age, rollback path, and exceptions.
Bound DNS checks and cache them with an explicit timeout/error policy; a slow resolver must not exhaust signup workers. Send ownership verification only after appropriate abuse checks, and cap dispatch per destination, account, network signal, and globally as needed. Protect against email bombing; blocking disposable domains alone does not protect a victim's ordinary inbox.
The IP address is a shared clue
A campus can place many legitimate people behind one NAT. An adversary can distribute requests across many networks. Combine account, device/session, network, and behavior evidence with clear retention and privacy boundaries. Client-provided IP headers are not trustworthy unless your edge strips/replaces them under a controlled proxy chain.
Synthesizing vector architecture diagram...
This is a policy framework, not a fixed scoring formula. Calibrate thresholds in shadow mode, segment false positives by device/network/access method, and provide an accessible recovery/support path. Avoid fake success messages that strand legitimate users indefinitely. A vendor's compliance statement does not certify your whole flow.
Measure harmful resource use, appeal outcomes, conversion loss, challenge completion, email complaints, and cost per allowed action. A lower signup count alone does not distinguish successful defense from blocking customers.
Mental model: Sybil resistance is about the cost and consequences of multiplying identities. Per-identity counting is one layer after that assumption, not proof of it.
Transfer: the classroom launch
A legitimate class of forty students shares one IP and signs up together. Your IP rule blocks all but five. Which response improves both evidence and safety?
Source trail: 25-bot-defense-sybil-resistance-and-registration-abuse, 26-honeypot-fields-and-canary-traps, 27-disposable-email-and-domain-blocklists. See the source map for consolidation and reference-retained material.