Turning the Rate Limit Against the User: The Invisible Vulnerability That Locks Out Any Account at Will

A consumer platform with accounts keyed on a mobile number. Signing in sends a one-time code to that number; entering the code creates the session. Account recovery works the same way. This is a design used by a very large number of consumer services, and most of what follows applies to all of them.

The authentication and recovery flows were the scope. Rate limiting was already in place on them, which is what makes this one worth writing up: a control that exists is the control nobody goes back to test.

The code-sending endpoint was rate limited. The limit counted requests against the number the code was being sent to.

So the allowance did not belong to the caller. It belonged to the customer. Anyone who knew a customer’s number could spend that customer’s allowance, from any source, and the platform would then refuse to send that customer a code. The customer could not sign in. Nothing had been compromised, and they were locked out of their account.

It could be held open

There was no cap over a longer period, only the short window. Repeat the requests as the window resets and the account stays unreachable for as long as the attacker cares to continue. This is the difference between an inconvenience and an outage for a named individual.

And the input was not what the platform issues

The number field accepted values that the platform’s own rules should have rejected before anything was spent on them. That is a cost problem, since each attempt sends a message, and it is a reconnaissance problem, because responses differed in ways that indicated whether a number corresponded to an account.

A rate limit exists to stop an attacker consuming a resource. This one let an attacker consume the customer’s resource, and the consequences are worse than they first appear for three reasons.

• It scales. A list of mobile numbers is not difficult to obtain, and the request that locks one account locks ten thousand with no more effort than a loop.
• It is invisible. Nothing in the logs describes an attack. It describes a series of code requests for a number, followed by a customer who cannot sign in, which is indistinguishable from a customer having trouble.
• It is unfixable by the victim. There is no action available to the account holder. They cannot change what an attacker sends, and support cannot reproduce a fault, because the control is doing precisely what it was configured to do.

Removing the limit is not the fix. Uncapped code sending is a direct cost and an easy way to make a customer’s phone unusable. The fix is separating the two jobs the single limit was trying to do.

1. 1Put the enforcing limit on the caller: source, session, device, account context. That is the party you are trying to slow down, and it is the only key where refusing service refuses it to the right person.
2. 2Keep a per-recipient cap, because message cost is real, but make its failure mode a delay rather than a refusal. Slow the next code down; do not decline to send one.
3. 3Add a longer window on top of the short one, so the pattern cannot be held open by waiting for a reset.
4. 4Validate the number against the format the platform actually issues before spending a message on it.
5. 5Alert on the shape rather than only enforcing against it. Repeated code requests for one number from many sources is a pattern worth surfacing, and it is the signal the original design threw away.

The general version of this, including the account lockout variant that hits password logins in exactly the same way, is in the guide on rate limiting that locks out users.

Go and look at what your own limits are keyed on. If the counter is attached to the account, the phone number, the email address or anything else chosen by the person on the receiving end, then somebody who is not that person can drain it. The question to ask of every threshold is not how high it is set. It is who suffers when it is reached.