Church of Wifi WPA-PSK Lookup Tables

This page is to give a little more insight into the methodology and
logic behind concieving and building the CoWF WPA-PSK Lookup Tables

Files are available via BitTorrent, direct tarball download by set (33gb or 7gb) or by ordering a set of DVD's from the RenderLab for either set.
Hosting for the torrent and tarballs graciously provided by The Internet Archive

Please send mail to render AT renderlab DOT net for payment information and shipping cost. Paypal is the only form of payment accepted at the moment. The DVD's contain the same information as is freely available for download. I am offering them as an alternative to
downloading only. I'm not trying to make major money off them. Any profit will be directed back into projects at the RenderLab

In the case where you cannot use paypal and can make a good offer, I will also trade for swag (t-shirts, challenge coins, other neat stuff) of roughly the same value. These are on a case by case basis.

Why

It's been known for a while that WPA-PSK was vulnerable to brute force
attack. Tools like Aircrack and coWPAtty took advantage of this weakness
and provided a way to test keys against dictionaries.

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

WHO

Before I get to far, This project was initiated by me but with a huge
amount of help and support from many others. It's thier work that should
be applauded. Ideas are cheap, work is not.

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:

WHAT

At thier heart, rainbow tables are the embodiment of the
Time-Memory trade-off. They are basically a giant version of your grade
school multiplication tables. In those tables, given 2 numbers you can
quickly lookup the result for that equasion without doing the more complicated math. The
trick is that at some point, someone had to invest the time to do the
complicated math in order to fill out the table for you to reap the
benefit of a quick lookup. This is the heart of the Time-Memory trade
off; It is often easier, cheaper, and more effecient to do the calculation
once and store the output for later repetative use, than doing the math
over each time.

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

HOW

For the WPA-PSK tables we knew that it would be impossible to create a
lookup table for all possible keys. Because the seeding of the algorithm
with the SSID and SSID length meant that we'd have to compute all possible
keys against all possible SSID's, the storage space required for this was
well beyond our capabilities to provide or even calculate.

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!

Ass covering

The fact that we found a way to speed up
WPA-PSK cracking does not mean that it is broken. Far from it. The
exploit used by coWPAtty and other similar tools is one of dumb
passphrases. The minimum number of characters for a WPA-PSK passphrase is
8. The maximum is 63. Very few users actually use more than about 20
characters. As well, they also choose known words and phrases, likely to
be in a dictionary. This allows us to leverage a human element in
obtaining the key.

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.

Please send mail to render AT renderlab DOT net for payment information and shipping cost. Paypal is the only form of payment accepted at the moment. The DVD's contain the same information as is freely available for download. I am offering them as an alternative to
downloading only. I'm not trying to make major money off them. Any profit will be directed back into projects at the RenderLab

In the case where you cannot use paypal and can make a good offer, I will also trade for swag (t-shirts, challenge coins, other neat stuff) of roughly the same value. These are on a case by case basis.