Wi-Fi Security: Cracking WPA With CPUs, GPUs, And The Cloud

[STravis]

[citation][nom]freggo[/nom]Question : If you 'test' 100,000' password a second do you use this on a bit of data captured from the network or do you actually contact the router 100,000 times ?If the later is the case simply limiting the password check speed of the router to 1 password/second would solve the problem.Just like you do on a website login. Either limit the speed at which you can submit your password, or limit the number of falsoe entries you are allowed.[/citation]

For WPA2 you don't need to do anything to the router OTHER than to capture the handshake. Once the handshake is captured you go about trying to break it - of course by the time you break it, the password may have already changed.

 

[Guest]

By the way you can test security of your wireless network using online services (gpuhash.com for example)

 

[no-one-here]

I know this is an old article, but I just couldn't resist commenting on it...

First, a couple of things I find strange in it:
- Minimum password length for WPA is 8 characters. The 1-5 and 1-8 character bruteforce examples are therefore a bit out of place there.
- Sending every to-be-tested password variation over the network is ridiculous. Even sending them one at a time to the graphics card is waste of machine's bus bandwidth (even though I doubt there would be enough of data to saturate it completely). Any distributed cracking system would split up the searched space in a logical way and have a mechanism (centralised or paxos-based) for tracking checked blocks and dividing the rest of the workload amongst workers. Only necessary negotiation + the seed key for the local generator would need be passed over network, which makes the perceived bandwidth-bottleneck go away completely. As a side note, Amazon's reserved & spot instance pricing also makes on-demand distributed cracking slightly cheaper, than one might first perceive.
- It probably ought to be mentioned, that one can build hardware to do required calculations much faster, than what you can do in the software even on a box running 4 top-of-the-line GPUs. I recall that's how cloudcracker.com gets to their numbers (15M tries/minute).

There are also a couple factors, which reduce the searched password space for typical cases (if you're satisfied to get a password to one AP out of multiple ones available):
- People often need to type in wifi passwords on mobile devices, so most tend to be short (

 

[no-one-here]

I guess the previous comment was too long... here's the rest of it:
--snip--
There are also a couple factors, which reduce the searched password space for typical cases (if you're satisfied to get a password to one AP out of multiple ones available):
- People often need to type in wifi passwords on mobile devices, so most tend to be short (

 

[no-one-here]

... It was the "lower than" character, then... Here's another go
-- snip --
There are also a couple factors, which reduce the searched password space for typical cases (if you're satisfied to get a password to one AP out of multiple ones available):
- People often need to type in wifi passwords on mobile devices, so most tend to be short (less than 16 characters), have low entropy and are limited to a specific character subset.
- There are certain patterns, which are more likely to occur than others. E.g. dictionary words and pronounceable letter combinations with a few number/special character spacers or substitutions.

So, all-in-all, if you're paranoid (as I am), use a good long password and you'll likely be safe. Most people, however, will not do that and someone interested in riding a free wifi will go after the lowest hanging fruit, likely succeeding at finding one if they have enough AP's in their area and tenacity to run a broad enough dictionary attack against all of them.

 

[eriko]

[citation][nom]fstrthnu[/nom]Well it's good to see that WPA(2) is still going to hold out as a reliable security measure for years to come.[/citation]

Hate to burst your bubble, ok that's a lie, I'd love to burst your bubble, here are some numbers from my Alienware M18x R2, with dual 7970Ms installed (I'll put up examples on Youtube when I get some more time):

Pyrit benchmark_long: 128,000 PMK/s. Now this is just the speed you get from an 'attack_passthrough'. i.e. using Pyrit to check against a known wordlist. Using Pyrit against a 1.9GB wordlist has not yet failed to find the result, but moving on...

But Pyrit is all about the database feature really, and with near 0.5 Bn words in my database (and yes thats with Pyrit disallowing / removing duplicates, and words that are too short or too long to be a WPA passwords too), we must first pre-compile for our chosen SSID, for all possible combinations. On the few occasions I've used it, it takes up to 40mins to pre-compile, but at least its automatic; pyrit -e dlink create_essid, then pryit batch.

Come back in 40 mins, and you can see the database ready. Now read in your capture file, and it will attack the DATABASE this time, at an almost unbelievable speed of 3.2M PMK/s to 4.8M PMK/s, you sit there and watch the speed vary.

Passwords cracked in no time...

EC2 eat your heart out.

Addmittedly this is done on 4 Ivy cores @ 4.4GHz, reading from dual 240GB SSDs in RAID0, with RAM @ 1866MHz, not an everyday laptop, I agree.

Other things to note, Linux knows not what to do with the dual GPUs on battery, unlike Windows, so trys to run them in their normal higher power state, which means, its all a buggy mess, if you try to batch, or attack on battery - system can't cope at all.