What is the speed and frequency that hackers can bypass rate limiting continuously in a website using login with an SMS OTP? The rate-limiting activates if the same IP address triggers SMS OTP more than x times.

  • 15
    tl;dr Depends what you mean by "their"! Mar 31, 2020 at 20:54
  • 1
    Using something like Tor you could easily get a new IP address for every request in a lot less than a second. On top of that you can parallelize the process, in case you need around (for example) two dozen new IP addresses every second ... Been there, done that.
    – Num Lock
    Apr 2, 2020 at 13:21

5 Answers 5



If someone has access to a botnet, even a small one, they could change the IP that their actions are coming from several times per minute or flood their actions from a million IPs in any given moment.


For individuals without a botnet, there are several methods, including resetting their ISP modem, which, in some cases, resets the IP. Turning a phone's airplane mode on/off can also trigger a change in IP (MechMK1 reports this might take as little as 3 seconds to complete).

They could also change between public WiFi networks.

Using a series of VPNs and proxies or VPNs that permit the user to choose the exit node will also work, and services that have different exit nodes can make this switch in seconds. There are also proxy/Tor utilities that can randomise your IP according to a schedule you set. The Janus tool has a default change time of 1 minute, but that can be changed.

Therefore, for any practical case, if the attacker is waiting for the SMS code to come back from your server, then they are only limited by the time it takes to receive the SMS code.

  • 8
    To add some real data, on my mobile phone connection, it takes about 2.5 seconds to get a new IP address.
    – user163495
    Mar 31, 2020 at 9:55
  • 8
    Activating and then de-activating airplane mode. It gives me a new IP address every time.
    – user163495
    Mar 31, 2020 at 9:56
  • 1
    Let us continue this discussion in chat.
    – kaizen
    Mar 31, 2020 at 10:25
  • 5
    @AndrewMorton aside from running a botnet that they, themselves, own and proxies? Not really.
    – schroeder
    Mar 31, 2020 at 18:13
  • 5
    @schroeder presumably a state level actor could own a block of IPs to themselves (or co-opt any IP within their jurisdiction) and could have a single server using millions (?) of IPs, no botnet required. I don't think it really makes a difference though.
    – mbrig
    Apr 1, 2020 at 5:25

No one seems to have addressed this yet, but I'd like to introduce the biggest problem to IP based rate limiting: IPv6.

If you (naively) applied the same logic as you do to IPv4 addresses to IPv6 addresses (i.e. block the address after a certain number of attempts), your rate limiting will be thwarted in about zero seconds.

Why? Well, the simple version is that IPv6 addressing scheme is substantially different than IPv4. IPv4 is rationed to the highest degree, so much so that even multiple homes and physical city blocks may have the same external address. This greatly contrasts with IPv6 where each machine, by convention, will have a /64 block addresses assigned to it. If you aren't familiar with the /x notation, this means that the first 64 bits of the address are fixed while the rest are left free. Since IPv6 addresses are 128 bits long, this means that each machine, by convention, has 2^64 unique addresses which it can use as it pleases! If you used the same approach as with IPv4 and simply blocked one address, the attacker could simply pick a brand new one from their essentially infinite pool of addresses! Your rate limit is then absolutely destroyed and they can submit an unlimited number of OTP codes as quickly as they want. This arguably makes your 2FA implementation useless since if your OTP code is six digits long, the attacker just needs to keep flooding you until they get lucky. In my real world testing, I found I could break a six digit OTP using this method in under six hours using a single thread so it's very practical and a very real threat.

What can we do to stop this? The natural choice would be to ban the entire /64 block of the requester when they hit the limit instead of just their specific address. On the surface, this seems suitable as it means that the attacker can no longer use any of the addresses in their pool.

This, however, also doesn't work even though far too many companies think it does. The problem is that while a host is generally assigned a /64 by convention, networks are designed to have more than one device on them! This means that even home networks will have oodles of /64 blocks (because why not? we're not going to run out!) given to them so that they can handle a bunch of devices. In my case, I was given a /56 block by my ISP to break up among my devices as desired. This means I actually have 2^8 (or 256) /64 blocks to hand out and break up among the devices on my network as I please.

Since there's nothing stopping me from handing the entire /56 block to one host, that means I have 256 /64 blocks at my disposal to cycle through and circumvent your rate limiting. If you let your users try five OTP codes per /64 block before banning them for some period of time, the attacker (using a residential connection!) would be able to hit you with 1,280 codes before they had to wait for the cooldown period. Compared to a classic IPv4 circumvention attempt (using a botnet, proxies, etc) this is an enormous gain for essentially just using what they already are given for free. If you combine this with a botnet (or even just by paying a small amount for a larger "enterprise size" IPv6 pool), IP based rate limiting is thwarted again for very very cheap.

So what now? Do we start blocking /56s for the purposes of rate limiting? You could, but this would have pretty unfortunate effects since although some people are given /56 blocks, others aren't and so you may very well end up accidentally blocking random people for no reason while not solving the problem of easily buying /52 and /50 blocks. The next reasonable choice would be to try and deduce what range assignment a request is originating from. While this would work, it isn't exactly possible as ISPs do not publish or release this sort of information. With this off the table, we (as far as I know!) are out of options. IP based rate limiting fundamentally does not work on IPv6 against an attacker who actually understands how IPv6 works.

But all is not lost! While IP based rate limiting is useless, rate limiting as a concept is not yet dead. You simply need to pick a different resource to limit access to. Instead of limiting the number of times an IP address (or range, or block, etc) can attempt to attempt OTP verification, you should limit the number of times an account may have OTP performed against it. By locking out the account after a certain number of failed OTP attempts and requiring the user click a link in their email to reactivate OTP, the attacker will not be able to bruteforce the OTP for the account no matter how many addresses they can wield. By setting this limit fairly high (say around 25), a normal user should never be inconvenienced by the policy unless something is very wrong with their authenticator (and so would probably need to initiate recovery anyways).

Such a technique has been used effectively by Instagram, Facebook, LastPass, and likely many more for both SMS reset codes and OTP. It is very effective and, in my opinion, the only safe way to block brute force attempts in a world where IPv6 is no longer simply ubiquitous but often mandatory as quite a few networks (mainly mobile!) are slowly transitioning to IPv6 only and using proxies to access 'legacy' IPv4 resources.

  • 3
    It's not correct that each Machine has a /64 block, each Network has one.
    – Josef
    Apr 1, 2020 at 9:15
  • 2
    @Josef: The opposite is not always correct either. I agree that machines are not usually assigned /64s "by convention" (that's just a common misunderstanding of ifconfig output) – but for example, in hosted VPS environments, often customers are indeed given a /64 per VM. In LTE, at least from what I've heard, each device gets its own /64. In some LAN networks, a machine could easily get a /64 using PD from the local router (e.g. for hotspot mode or virtual machines).
    – grawity
    Apr 1, 2020 at 11:11
  • 4
    I've had an ISP that assigned /48 to my home. That's possible too! It's indeed useless to try IP ratel imiting.
    – Gizmo
    Apr 1, 2020 at 11:25
  • 7
    Account-based ratelimit lets someone DoS your ability to log in to your account. IP-based rate limiting does not. So there is a potential downside. Apr 1, 2020 at 17:28
  • 1
    There are standards about the allocation size; this "answer" is more fearmongering for the big evil IPv6 where you can no longer ban evil hackers, than helpfully telling us what a typical allocation size is and that you should indeed just consider the subscriber's allocation size to be a single subscriber.
    – Luc
    Apr 2, 2020 at 15:40

If a hacker is in posession of a botnet, they can have control over thousands of IP addresses and can switch between them at will. So there is not really a practical limit to the frequency and speed with which they can change IP addresses.

  • 6
    Thousands probably being a relatively small botnet...
    – jcaron
    Apr 1, 2020 at 16:09
  • 2
    The Srizbi botnet was the biggest at around half a million machines Apr 2, 2020 at 3:25
  • Important thing to note is that they're probably already attacking with other IP addresses before you've had a chance to block anything.
    – bobsburner
    Apr 2, 2020 at 10:43
  • 2
    @MooingDuck Srizbi was taken down in 2008. Since then ... there have been much, much bigger botnets .... en.wikipedia.org/wiki/Bredolab_botnet and en.wikipedia.org/wiki/Conficker to name just a couple. Mirai was 600,000. In 2016, you could rent a 400,000 node botnet.
    – schroeder
    Apr 2, 2020 at 10:44

Using cloud providers you can “rent” a great number of IPs for a short amount of time. This is much easier than botnets/tor/switching off our phone/etc. (edit: although potentially more risky in terms of covering your traces, see comments).

The whole thing can be fully automated, for instance with Amazon API Gateway.


  • 1
    "Easier" is relative. You need to set up accounts, set up payment to AWS, and configure from scratch. Renting a botnet is far more streamlined. And by using cloud services this way, you expose yourself. Renting a botnet provides separation between you and the attacking traffic. AWS/Google cloud is perfect for research, but limiting and exposing for attacks. I would use AWS for exactly what the authors did: to simulate a botnet, but not to actually be one.
    – schroeder
    Sep 11, 2020 at 12:53

This depends on the network between the attacker machine and your server. If it is across the world, the attacker may be limited to single IP address or small number of them. Some cloud providers allow to change IP address of the virtual machine in the cloud the attacker may own, or the attacker may just start another virtual machine. Scripting support may be limited and the action may require multiple seconds at least.

If both computers are inside the same local network, it may be possible to change IP address of the attacker with a single command. That command can be launched from something like Python script that does the rest of attack and take only milliseconds to execute. It must be run as root but this is unlikely to be a big problem.

  • This answer assumes the remote attacker only has one machine and one network and uses one cloud provider. It also seems to ignore all the rest of the factors presented in all of the other answers.
    – schroeder
    Apr 2, 2020 at 10:49
  • The question is how fast it is possible to change the IP address of a machine, I assume, a single one. How it is relevant how many machines or networks the attacker is actually using?
    – h22
    Apr 2, 2020 at 15:06
  • The OP does not specify "IP of a machine". You've added that assumption.
    – schroeder
    Apr 2, 2020 at 15:08
  • Also, VPNs/Proxies allows a single machine to have virtually unlimited IPs.
    – schroeder
    Apr 2, 2020 at 15:09
  • 1
    You don't think that the use of botnets to brute-force credentials and stay under rate-limiting thresholds and IP-blocking measures is relevant? That's a very strange opinion to have since that is a core use case for botnets ...
    – schroeder
    Apr 2, 2020 at 15:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .