Blocker #1: sequential requests
So in your current setup:
- passwords are sent to the server one at a time
- you wait for one response before sending the next
With a module like time
you can see how much CPU time is spent waiting for server responses, vs. other stuff in each loop to determine your duty cycle (work/vs. wait time, per loop). If your duty cycle is 20% (i.e. 1ms work, 4ms waiting), then you should be able to easily run 5 parallel requests.
Blocker #2: single-core operation
If you saturate your CPU[core] by having multiple requests waiting in parallel, and you have a multi-core CPU (say 4 cores, or nc=4
), you should be able to have 3x (nc-1 = 3
) as many requests in parallel. (See my other post here on why you can't just go to 1000 threads and expect 1000x the performance: https://stackoverflow.com/a/68667749/10761353)
Blocker #3: server capacity
Your server will only be able to answer a certain number of requests per second. So even if your PC (e.g. with 4 cores, and thus 3 cores x 5 threads/core = 15 threads
) making many requests in parallel, the server may only be able to process (e.g.) 10 requests/second, in which case you would likely:
- consume all available [server] response resources,
- receive some kind of error for (e.g.) 5+ out of every 15 requests/sec,
- drive up their usage bill (probably),
- exclude legitimate users from accessing the page/site, and
- trigger abuse protection/monitoring, which brings me to my last point
Blocker #4: Abuse prevention measures/systems
Companies like serving their customers - it's usually how they monetize. When legitimate users can't get in due to denial of service (DoS) attacks (whether trying to bruteforce/guess a password, or just be a nuisance), companies naturally don't appreciate this and want to stop it (ever heard of the little startup called Cloudflare?). Measures include:
- requiring a Captcha in addition to the password, when traffic patterns become suspicious
- slowing/dropping requests from IPs that are making too many requests
- blocking/banning access from IPs that have made too many requests in the past
- locking out user accounts after too many failed login attempts
- and many, many more.
TL;DR
- multithreading can be useful for parallelizing when your taks(s) have lots of wait-time, or you have a multi-core CPU - most are nowadays)
- brute forcing a web-based service is not really practical in 2021 (and definitely not the mark of a good netizen)
- brute-forcing a password hash can be accelerated quite a bit using powerful GPU(s), effectively taking the site's operational protection out of the guessing loop.