Beta

Create a tenant

A new tenant starts with its own users, OAuth settings, audit history and logs. You are its first Tenant Admin.

BTL Admin

Fake accounts and message abuse

Not every attack wants an existing account

The photo application gives each new customer a month of extra storage, plus a credit for every friend they refer. One weekend, sign-ups jump tenfold. The new accounts have random-looking names, addresses at a handful of little-known email domains, and a habit of referring each other. None of them uploads a photo. They exist to collect the credit.

Not every attack on identity is after someone else's account. Fake accounts are created in bulk for what an account can do on its own: claim promotions and trial credit, post spam or scam links in public albums and comments, inflate likes, followers or reviews, or sit quietly until they are old enough to look trustworthy. Here the target is the sign-up form, not the sign-in page.

In the records, a wave of fake sign-ups shows up as a burst of new accounts from a small set of networks or devices, addresses at domains that hand out throwaway mailboxes, names that follow a pattern, and accounts that claim a benefit and never come back. Any one of these can be innocent. A school signing up a whole class arrives from one network too. Together, they make a pattern worth acting on.

As Establishing an identity explains, creating a record does not establish who is behind it, and verifying an email address shows only that someone can read that mailbox. A script can create mailboxes too. That does not mean every sign-up needs identity proofing. It means a benefit worth abusing should depend on more than an account existing.

Making your service send the messages

Sign-up, sign-in by email link, password reset and phone verification all send a message to an address someone types into a form. Normally that someone is the owner. Nothing in the form stops an attacker from typing a victim's address instead, thousands of times.

The victim's inbox fills with genuine messages from photos.example: welcome emails, reset links, verification codes. A message flood like this can be the goal in itself, as harassment, or cover for something else, since a real security alert or purchase receipt is easy to miss among three thousand reset emails. The service suffers as well. Mail providers notice a sender whose messages nobody wanted and start filtering them, and the next genuine customer's reset link lands in a spam folder.

Text messages add a cost. Every verification text costs the service money, and part of that charge goes to the carrier that delivers the message to its final number. In SMS pumping, also called artificially inflated traffic or toll fraud, the attacker works with whoever controls a range of numbers, often through a carrier willing to share those delivery fees, and submits numbers in that range to a sign-up or verification form again and again. The service sends thousands of texts and pays for each one, and the attacker collects a share. No account is taken over, and nobody ever enters the codes.

Both patterns are plain in the records once someone looks. A flood shows many requests for one destination, often from many sources. SMS pumping shows verification texts concentrated in a few countries or number prefixes, arriving faster than usual, with almost none of the codes ever entered.

Locking people out on purpose

Guessing, spraying, and stuffing describes how locking an account after a few failed sign-ins can be turned against the people it protects. Seen as an attack in its own right, it is cheap and reliable. Anyone who knows an address can fail a sign-in a few times, and a script can do it every morning. A seller on the photo application can be locked out each time a sale begins, or a whole support team at once.

Reset flows can do the same if they are careless. A service that disables the current password as soon as someone requests a reset lets any stranger sign a customer out and push them into recovery. A reset request should change nothing until it is completed by someone who controls the channel the link was sent to.

The defenses are the ones that work against guessing: slow attempts down instead of locking the account, and keep a path open for the owner. The person can keep signing in from a device that has signed in successfully before, or with a phishing-resistant method that failed passwords cannot affect, while attempts from everywhere else wait longer and longer.

Limits that real people rarely notice

Each of these abuses works by repeating, at scale, something a real person does once or twice. A customer requests a reset when they forget a password, verifies a phone number when they sign up, and fails a sign-in when they mistype. Limits set just above that pattern stop the abuse while staying out of everyone else's way.

The useful limits key on more than the account. A per-destination limit caps how many messages one email address or phone number receives in an hour or a day, however many people ask, which ends a flood directly. Per-network limits cap how many sign-ups, resets or texts one source can request. A sending budget caps what the service spends on text messages each hour, with an alert well before the cap is reached, and sending can be paused for number ranges or countries where the service has no customers.

Benefits can wait for evidence. Trial credit and referral rewards can be granted after an email address is verified and the account has done something real, such as uploading photos over several days, instead of at the moment of sign-up. New accounts can start with small limits on sharing, posting and messaging that grow as the account ages and behaves well. This kind of gradual trust costs a genuine customer almost nothing and removes most of the value of a fake account.

Watching a few numbers ties these limits together: sign-ups per hour, messages sent to each destination, the share of verification codes that are actually entered, and text-message costs by country. When a real person does reach a limit, the message should say what happened and when they can try again, so that a rare collision with a limit does not turn into a support call.

Try it in the Lab

PUT IT INTO PRACTICE

Check your understanding

Try these questions before moving on. If an answer isn't right, use the feedback and try again.

0 of 2 answered correctly

Enable JavaScript to answer these questions and save progress in this browser.

QUESTION 1 OF 2Overnight, thousands of verification texts go to phone numbers in a few prefixes, and almost none of the codes are entered. What is happening, and what limits it?

QUESTION 2 OF 2Overnight, one customer receives three thousand password reset emails from photos.example, requested from hundreds of different networks. Which limit ends this most directly?

We value your privacy

We use cookies and similar technologies to enhance your browsing experience, and analytics to understand our traffic. By clicking "Allow All", you consent to optional analytics. Cookie Policy

Learn identity