# How to calculate brute forcing times/feasibility for remote attacks to include parallelism?

This is purely a thought exercise.

Assume a server which does not implement throttling or lock on failed attempts. The server accepts a username/password request & sends back a Yes/No response. The response time is 10 seconds. You are trying to brute force a password on the server. I am trying to figure out how much time it would take to brute force say a 5 digit Numeric PIN.

The entropy of the PIN would be 105 = 100000 So the time taken to brute force would be 100000/10 = 10000 seconds.

However, you can have a multithreaded program sending requests in parallel. Or multiple programs running at the same time doing the brute forcing. So my naive calculation is not correct.

Assuming the attacker's machine a typical laptop of today (i7, 16 GB RAM), how do I calculate the time taken to brute force - are there any thumb rules for this?

• It is 100000*10(/2) for sequemtial checking, for parallel it mostly depemds on why the server takes 10s, if this is a delay then you can use a parallelity of 100 by which you would improve the time. It is a CPU bound delay then parallel may only speed it up by the number of server cores. If it is a global throttle then no parallel improvement at all. – eckes Jul 30 '17 at 20:05
• assuming it wasnt cpu bound on the server side as @eckes suggest ... I think the network card would be your next major bottle neck ... how big is the authentication traffic? Does it maintain a TCP/IP session for the full 10s? How many sockets can client/server OS maintain at once? – CaffeineAddiction May 3 '18 at 3:16

In the real world, the main bottleneck would be the number of connections. Most server implementations, especially webservers, rate-limit this, not just for security reasons (to combat your exact scenario), but also for reasons of fair resource sharing and to throttle runaway clients.

Even if they don't throttle it, a server can only handle a limited number of concurrent connections.

For example, the default configuration for apache2 is set to 150 concurrent connections. That is the hard limit for an attacker, and under realistic circumstances, at least a few of those connections will be busy handling legitimate users.

So the proper answer for n depends on your server implementation first, and other factors second. For a simple scenario like yours, it is trivial to write a client that can saturate the server with requests, the client will not be the bottleneck for any halfway competent attacker, the server will be.

• this is also dependent on the OS running the clent/server ... Linux can maintain many more concurrent connections than windows ... but both have limit's – CaffeineAddiction May 3 '18 at 3:19
• Correct, the OS can be as much the limiting factor as the server software. – Tom May 3 '18 at 15:35

Assuming it's a magical server:

Time: time per attempt

1 thread mean time: combinations * time/2

n thread mean time: combinations * time /(2 * n)

• My question is to ask what would be the right value of `n` to assume for a normal lapop of today? – user93353 Apr 1 '17 at 6:16
• Depends on the implementation and a lot of other factors. Could be 5000, could be 65536, could be 4294967296. You'd need to see how much processing power one iteration takes. – guest Apr 1 '17 at 10:27
• one iteration is just small request & a small response. Few bytes of data each way. There isn't any computation at all or much processing at all. What are "a lot of other factors"?. And it cannot vary between 5000 to 4294967296 - that's utter nonsense. – user93353 Apr 1 '17 at 15:34

Typically the way you would determine an appropriate value of `n` is to figure out how many computational resources are necessary for each attack thread, then divide that into the resources that could feasibly be obtained by an attacker. Traditionally this meant looking at a standard desktop machine, but nowadays, even for individual attackers, the availability of computer rentals through AWS and similar sources has made it easy to quickly and cheaply gain access to a fair bit of computing power. If you're concerned about nationstates, then the budget you allocate for machines is higher - but it's all an estimate.

So how exactly do you determine how many attacks can run in parallel, once you've chosen your hardware? The simplest answer is to benchmark it - acquire that hardware (or a fraction of it) and see what the throughput is. And make sure to record your setup (what hardware, specifically, what OS, what versions of important libraries, what compile flags you used) so that reviewers can make suggestions on how to make the attack process more efficient.

• I am asking only for a standard desktop/laptop. And my question is all about asking to how to determine the value of `n`? – user93353 Apr 1 '17 at 15:35
• @user93353 I updated it. – Xiong Chiamiov Apr 1 '17 at 17:37