Here are the Church of WiFi coWPAtty Uber lookup tables, all I (Spliff666) have done is download a torrent (at alarmingly fast speeds thanks to nice seeders) and have unzipped it and reuploaded so that instead of the 33Gb download that you may not require you can simply download a 40Mb file just for the SSID you need
The rest of this writeup is taken from
Problem is, it's a very slow process. Each passphrase is hashed 4096 times with SHA-1 and 256 bits of the output is the resulting hash. This is then compared to the hash generated in the initial key exchange. Alot of computing power is required for this. My dopey little P3/700 laptop only tests about 12 passphrases/second.
To complicate matters, the key hash can be different depending on the network it's implimented on. The SSID and the SSID length is seeded into the passphrase hash. This means that the passphrase of 'password' will be hashed differently on a network with the SSID of 'linksys' than it will on a network with the SSID of 'default'.
For the DC13 Wardriving contest there was one contest that was particularly infuriating. "The Last Crusade" had contestants attacking a series of access points to connect to a server behind it, each one's security was stronger than the previous. The last AP was WPA-PSK. 3 hours was slated for the contest, 1 hour was spend on the 4 previous APs'. We spent the last 2 hours running coWPAtty on 2 laptops and ended up failing to get the key. The last 2 hours were very boring.
After the contest I began thinking that there had to be a better way. Eventually the planets aligned and I figured out a way. Problem was, how to get it accomplished
RenderMan: Initiator, argent provocateur
Joshua Wright: Original author of coWPAtty, added code to make this project a success. Coding god
Thorn: Moral support, sounding board, critic
Dragorn: Ass saving CPU wrangler and cool guy
H1kari: FPGA god who gave us access to dedicated hardware for generating these tables
Twitchy: CPU Wrangler and all around great guy
Other peoples work contributed in-directly to this, but they deserve mention:
Beetle: CPU wrangler for the Shmoo groups rainbow tables
Dan Moniz and Patrick Stach: Fellow Shmoo rainbow table conspirators
Philippe Oechslin: For a kick ass paper on the Time-Memory Trade-Off
The application of the Time-Memory trade-off is particularly useful in password cracking and cryptography. One of the barriers that cryptography uses is large keys. In order to test every possible key, the attacker faces a huge task that in some cases can take years.
However given the exponential growth of both processing power and storage, it's concievable that an attacker could invest the time to pre-compute a lookup table for every possible key in advance of the actual attack, and commit that result to some sort of storage. All future attacks now only require a quick lookup in the table and are very close to instant. After investing the initial time to build the table, they no longer have to re-invest that time for subsiquient lookups.
This technique can also be refined through various sorting methods which go beyond the scope of the CoWF tables for WPA-PSK
In 2005 the Shmoo group released Rainbow tables for LANMAN hashes, effectivly breaking NT password security forever. This project led to the inspiration for the WPA-PSK tables
Instead we looked at the project and broke it down into a way to quickly check WPA-PSK networks against known english words and known passwords quickly, while still leaving the option open for brute forcing the rest of the keyspace. Selecting the most effecient dictionary and SSID's computed became the focus.
Size was also a concern. As we wanted to be able to distribute the results, we did'nt want the results to be beyond the storage capacity of most users.
The first dictionary was a merged list of Websters dictionary, several lists of common passwords and the list of SSID's we were computing for. This list was sorted and all passphrases < 8 or > 64 were removed due to the minimum and maximum passphrase length in WPA-PSK. The grand total words was ~172,000
The SSID list was taken from the top 1000 SSID list on wigle.net. The SSID list came to represent about 52% of the Wigle database (at the time) of 5 million access points, which accounts for about 2.7 million known access points. We figured this would give us the widest possible coverage for public use (you could still compute your own hash tables for non-listed SSID's).
The resulting tables fit comfortably onto 2 DVD's
Joshua Wright, author of coWPAtty graciously accepted my suggestion of integrating pre-hash tables into coWPAtty and coded up the tool (genpmk) for us.
I spend the next month or so with a couple CPU's cranking away on the data, generating 1000 SSID's worth of hash tables from a 172,000 word dictionary. Towards the end I decided to test the hash files and get some metrics on how fast they computed. I setup a workstation to talk to a WPA-PSK AP with a passphrase that was known to be in the dictionary and captured the nessecary hash. I launched the attack with the coWPAtty 3.0 beta's and it was'nt finding the key. Eventually with Joshua Wrights help we dicovered where I'd screwed up. The password list had been saved in windows txt file format, leaving a hidden return character at the end of each line. This return character was being hashed in as part of the password giving me all wrong results!
Fortunatly, before commiting harikari for wasting a months CPU time, Dragorn offered access to a 27 node cluster. This cluster was able to compute the job up in about 3 days, and these files were working.
The result was a set of hash tables of about 8 gig total, comprising 1000 of the most common SSID's, computed for 172,000 dictionary words
Tests and a demonstration at Shmoocon showed that a p3/700 laptop without a hash table, tested keys at about 12 keys/sec. Including the hash table, the same laptop tested 18,000 keys/sec. 3 orders of magnitude faster!. What would have taken 4 hours to test previously, now was testable in 10 seconds.
This would be particularly useful for auditors wanting to confirm that WPA-PSK keys in use were not common words. Conversely this could also be used by attackers looking to find networks with easy keys, but as will be shown, that can be easily overcome.
We were not completely satisfied with this scenario and decided to go further and compute more words
Mark Burnett, noted password expert, donated his list of 400K actual passwords harvested through google giving us a highly targeted set of words that we know people have used. This was padded out with other obscure dictionaries (medical, etc) to an even 1 million words. Twitchy donated about 14 3 Ghz CPUs to do the work. After a month that involved him blowing several breakers and having to work topless to beat the heat, it turned out that I screwed up again and somehow the password list had control characters appended again!
It was at this time I was informed of H1kari's work in implementing the PBKDF2 hash function in hardware and showing massive gains in speed over a general purpose CPU. 1 card could compute 600 Keys/sec. He managed to hook us up with a box with 15 of these cards, effectivly doing over 9000 Keys/sec! What previously took Twitchy almost a month to compute, took H1kari 3 days. The end results barely fits on 9 DVD's and weighs in at about 33 Gb.
At this time we also had Josh Wright add code to support using coWPAtty to do the same attack on WPA2 which uses the same PBKDF2 key exchange, thus making the tables instantly capable of attacking WPA2 as well!
To get decent protection from WPA-PSK, you should use a very long, very random, alphanumeric string longer than 20 characters. To protect yourself further, particularly against the WPA-PSK hashtables, you should use a SSID not on the top 1000 list. This will force the attacker to compute thier own list, rather than use one of the CoWF tables.
All that said, you should be using WPA2 with a radius server to get more reliable protection.