Why Bruteforcing passwords does not work: how to calculate the amount of time it takes!
Written By
https://t.me/vimicito
I have recently been presented with a randomly allocated password of which I was curious to know: how much time will this take to crack by a bruteforce method?
First order of business is to look at the password (gpjs2nuw43wy5 in this case, randomly generated) and determine its character set. In this password it is safe to assume that the character set will probably only include lowercase alphabetic characters, but it does have some numbers in it. This will result in our initial conclusion: 13 lowercase alphanumeric characters, i.e. (26+10)^13 possible combinations. Its result is around 1.7e+20, and this will be the number we can base all our further calculations on. Even with a single uppercase character in your initial password, you'll have to account for uppercase anywhere else in your target password. This will result in your initial conclusion being (26+26+10)^13 instead, making it much more difficult to crack.
If you are in doubt about the character set and the exponent as number of characters, consider a simpler passcode — a 4 digit PIN code. The character set is 0-9 for each digit, i.e. 10 possible states per digit. Those combinations can go from 0000 to 9999, both inclusive. This gives you 10.000 possible combinations, or 10^4.
Next assumption I make will be based on the usage of the CUDA hashcat suite, a demonstration of which can be found
https://www.youtube.com/watch?v=7U-RbOKanYs. Let's also assume that this password was stored as an MD5 hash in a database. This is because it's by far the easiest to crack, clocking in at several billions of hashes computed every second (abbreviated to GH/s as we continue), and it's the hashing algorithm shown in this video. In the video, Mike Pound has achieved around 33.5GH/s across the various GPU's.
The means by which this password is stored does matter, as it will determine our GH/s rate. Since we're using the weakest hashing format available for this exercise, we can conclude that all the other ones will make things slower still.
Okay, so let's say that our computer can crack MD5 hashes at 10GH/s (it's a simpler consumer desktop that does not have 4 fancy graphics cards in SLI in it), this will make our calculations easier. We need to divide this 1.7e+20 by 1e+10, or 10 billion. The cool thing about scientific notation is that you can just subtract the value behind e for a division, so we end up with 1.7e+10. Easy, and at big numbers like this super useful!
Note however that the subtraction shortcut can only be used for numbers that have a matching base. In other words, if one of your numbers is decimal (base-10) and your other is binary (base-2), this won't work and you'll have to convert one to the other's numbering system first.
Now we have our amount of seconds we need to crack this password, which brings us into the time domain. This still very large number needs to be sliced up into larger chunks of time. 60 seconds for a minute, 60 minutes for an hour, 24 hours for a day, and 365 days for a year to be exact.
The calculation 1.7e+10/60/60/24/365 will end up in the number of years it will take to crack this password, ending our exercise. The number we end up with is a manageable, but still excessively large 540.9 years. Bruteforcing a password this large is not feasible with current GPU hardware, even with the weakest hashing algorithm MD5.
There are other means of getting a WiFi password, such as WPS and evil twin attacks. But I hope that this post made clear that bruteforcing is not viable for passwords with even a moderately large length. Why not ask for the password instead? Frame it well and people may be willing to give it to you in under 5 minutes.
![[🛡] MTProxyBoy Profile](/_next/image?url=https%3A%2F%2Fcdn.tgdio.com%2Fchannels%2F2025%2F10%2Fmtproxyboy.webp&w=256&q=75)
