Why one account per IP was the wrong rule

A signup form is the cheapest place to create accounts in bulk. The obvious countermeasure is to allow one account per IP address. We did not take it, because the rule is wrong about who shares an address.

A household, a university lab and an office behind one NAT all present the same IP. Hard uniqueness would block the second person in the building, not the script that rotates proxies. So the limit is a rolling one-hour quota rather than a permanent identity: successful signups are counted per browser and per IP, and all attempts are counted per IP. The browser quota is the tightest of the three, because a fresh browser profile is the cheapest thing for an abuser to obtain.

The human-check result changes the quota, not the verdict. Some browsers and networks fail the challenge for reasons unrelated to intent, so a single failure cannot mean rejection. Failures are counted; after three in the window, the same IP's attempt cap drops from thirty to ten and its success cap from ten to three. Someone who fails once and stops is unaffected. A client that keeps presenting itself is squeezed within a few requests.

The audit trail stores IPs only as HMAC-SHA256 with a server-side secret. We can count per address without keeping an address that can be read back, and counting is all the limit needs.

The cryptography here is ordinary. What matters is not encoding a false assumption — that one address means one person — into an access rule.