Reduce Fake Signups With IP Risk Signals

A fake signup is an account created to be misused rather than used. OWASP's catalogue of automated threats lists it as OAT-019 Account Creation: bulk account creation, sometimes with populated profiles, through the application's own sign-up process, with the accounts then used for content spam, laundering cash and goods, spreading malware, damaging reputation, and skewing search rankings, reviews and surveys. Add promotional abuse, referral fraud, free-tier farming, marketplace scams and scraping under many identities, and the list covers most of what security and trust teams see.

The economics explain the pattern. One account is worth little; a thousand are worth a campaign. So the attacker automates, and automation leaves traces in exactly the places IP data can see: how many accounts came from where, how fast, and through what kind of network.

Keep the two problems separate, because their signals and their remedies differ. Signup risk is about account creation: there is no history for this user, no established device, no known location, and the question is whether a person is creating one account for themselves. Login risk is about access to an account that already exists: there is history to compare against, and the question is whether the person at the door is the owner. OWASP draws the same line, distinguishing Account Creation from Credential Cracking and Credential Stuffing, which use existing accounts.

This guide is about the first problem. For the second, the credential stuffing guide and the login risk guide cover the account-history signals that signups do not have.

Velocity. Count signups per address, per /24 and per ASN over minutes, hours and days. A household creates one account, occasionally two; an address creating twenty in an hour is running a script or standing in front of many people. Slower farms space their signups out, so the daily and weekly counts per subnet matter as much as the burst.

Same IP, same subnet. Accounts created from one address or adjacent addresses that then behave alike (the same referral code, the same product listed, the same review text) are a cluster, and clusters are what account farms look like from the outside. Track the link between accounts and creation addresses even when nothing fires at signup, because it is what you will need when the abuse shows up later.

Hosting, proxy and VPN indicators. A signup form is built for people, so an address from a cloud or hosting network is unusual there, and a proxy or VPN exit is worth noting. Neither is disqualifying: privacy tools are legitimate and popular, and a corporate egress can sit in a data center. Treat them as one input to a score rather than a reason to refuse; the data center versus residential guide and the VPN and proxy checker cover the classification.

Disposable email correlation. Throwaway mailbox domains combined with a hosting address or a rotating proxy are a stronger pattern than either alone. A disposable address from a residential connection is often just a privacy-conscious person.

Device and account context. A device identifier or browser fingerprint that has already created several accounts, a form completed in under a second, or profile fields filled with the same template are behavioral signals that confirm what the network data only suggests.

The signals above break when many people share one address. Carrier-grade NAT puts thousands of mobile subscribers behind a single public address, using the shared address space that RFC 6598 reserved for it; a university, a hospital or a large employer routes a whole campus through a few egress points; a popular event fills one venue's Wi-Fi with genuine new users. A per-address signup velocity rule fires on all of them, and a hard block turns away every real person behind the address for as long as the rule stands. The CGNAT guide explains why one address can mean a crowd.

The fix is structural rather than a bigger threshold: recognize mobile and CGNAT ranges from the ASN and treat their velocity limits as soft, prefer friction to refusal, and use device and behavior signals to separate the individuals sharing the address.

Combine the signals into a risk score for the signup, weighting behavior and device context alongside the network data, and let the score choose a response. A network-level fraud score for the address is one input; it summarizes the address's recent history, not the intent of the person using it now. Log the score and its components with every account created, whether or not anything was triggered, so that when abuse surfaces a week later you can see what the account looked like at birth and tune the weights against real outcomes instead of intuition.

Match the friction to the score, and start low. A CAPTCHA or an equivalent proof-of-humanity challenge filters simple automation at almost no cost to people. Email verification confirms control of a mailbox and slows bulk creation; it is the reasonable default for a medium score. Phone verification raises the cost per account considerably and belongs where the account can do real damage, such as payouts, marketplace listings or messaging other users; it also excludes people who cannot or will not share a number, so use it where the value justifies that. Step-up review, a manual check or a delay before the account gains sensitive capabilities, is for the highest scores.

Two rungs are missing on purpose. Blocking by country turns away every legitimate user in a market over the behavior of a few, and blocking on the IP address alone inherits every shared-address false positive described above. Both belong at the very top of the ladder, for narrow, evidenced, expiring cases. OWASP's guidance on unrestricted access to sensitive business flows, whose examples include scripted registration for referral credit, recommends the same layered approach: device fingerprinting, human detection, and treating non-human request patterns as a trigger for friction.

None of this is identity proofing. NIST SP 800-63A describes the assurance levels at which an enrollment verifies who a person is; at the lowest, attributes are self-asserted and nothing is checked, which is where almost every consumer signup sits. The ladder above decides how much automation to tolerate, not whether the name on the form is real.

A signup defense that is never measured drifts toward refusing people. Track the share of challenged signups that complete verification, the share that abandon, and the appeals or support tickets that follow. Sample the accounts that were challenged or refused and check how many later turned out to be legitimate; sample the accounts that passed and check how many were abusive. Break both down by network type and country, because the cost of a rule is rarely spread evenly. Travelers, privacy-tool users and mobile users on carrier NAT are the usual casualties, and the numbers are the only argument that will change a threshold.