Alan November 10, 2008 1:33 PM

Based on what I’ve read, it is the TKIP encryption that is broken. So, contrary to what virtually every pundit is currently recommending, it is not necessary to abandon WPA in favor of WPA2. Instead, you need to move from TKIP to AES.

Note, TKIP is still optionally available under WPA2. So, after incurring all the cost of migrating from WPA to WPA2, you might still be vulnerable. Instead, just use AES.

Harry Erwin November 10, 2008 1:49 PM

I read the article during the weekend and made the switch. On my Airport system, it’s trivial to do, as it is the default for WPA2 authentication.

dragonfrog November 10, 2008 2:17 PM

@Chris, Clayton, Alan

To implement WPA, only the TKIP part of the 802.11i standard is mandatory. There may be some WPA-labelled devices that included an AES implementation, but it wasn’t necessary.

To implement WPA2, the full 802.11i standard, including both TKIP and AES, is mandatory.

Sid November 10, 2008 2:24 PM

Paper has been posted here last Saturday:

The paper is not about WPA as a whole, but about TKIP. It is a slight difference, but as it was stated earlier, AES support can be implemented in WPA and some stacks allow this setup. In this cas (WPA/AES), you’re not vulnerable.
WPA2 requires CCMP. TKIP support is optional, but most of the time implemented. Therefore, you can have WPA2 devices using TKIP, and they are exposed. Actually, I don’t remember having seen a single WPA2 implementation without TKIP support…
A very common situation is when you provide WPA and/or WPA2 with both TKIP and AES support. One could think only TKIP devices are exposed to this attack. This is not quite true: in such a setup, group traffic will be encrypted using TKIP, and is therefore exposed.

So stating “WPA cracked” is almost true. Advising “Switch to WPA2” is close to wrong.

Plug French speaking readers can find my own analysis here:

Alan (2) November 10, 2008 2:54 PM

The point is moot: so many people (and operating systems) still use WEP.

From a sysadmin’s point of view, wireless is going to remain a bad piece of business as long as people can evesdrop without needing physical access, i.e. forever.

Just my 2 cents…

Darren November 10, 2008 3:46 PM

Nope, TKIP was (maybe) cracked. Large enterprises who use EAP-PEAP, LEAP, or similar alternatives to TKIP are entirely safe.

Home users who have APs that allow AES with WPA are safe, though most of them should be using WPA2 anyhow.

And we haven’t actually seen it work yet or seen/evaluated the paper, it’s just a claim. Probably a true claim, but still.

Evan November 10, 2008 3:51 PM

James is right, check out the arstechnica article. TKIP keys haven’t been cracked so you can’t derive the PSK. You can decrypt short individual packets in 12-15 minutes and using a QoS flaw, replay those packets with modified data. You can’t crack and view all the traffic but you can probably do ARP/DNS spoofing/poisoning

Davi Ottenheimer November 10, 2008 4:57 PM

@ Sid

Thanks for the link. What I see in the paper is:
1) WEP is flawed
2) TKIP is (based on and) backward compatible with WEP, found to carry a similar flaw
3) Therefore, WPA inherits a WEP flaw if allowing TKIP communication

An attack currently depends upon:
1) TKIP used for client to AP
2) known IPv4 range (e.g. 192.168.0.X)
3) long re-keying interval (e.g. 3600 sec)
4) IEEE 802.11e QoS
5) client connected to the network

The authors offer a short re-key cycle as a workaround, which already is a best practice.

Davi Ottenheimer November 10, 2008 4:59 PM

@ Alan

“The point is moot: so many people (and operating systems) still use WEP.”

The regulators are catching up. For example PCI DSS 1.2 no longer allows WEP.

“wireless is going to remain a bad piece of business”

You could say the same about anything. Even wired security has flaws. The bar for security in a business, however, at least should be raised above FUBAR.

dragonfrog November 10, 2008 5:08 PM

Darren, you seem to be confusing two different parts of WPA(2)

TKIP vs CCMP (AES) is how the channel is encrypted once a user is connected. You must pick one.

Pre-shared keys or an EAP flavour (PEAP, EAP-TLS, etc.) is how the user and the network authenticate one another when the user is initially trying to connect. You must also pick one of these.

An overdone physical security metaphor, because we all like those – the authentication mechanism (EAP or pre-shared keys) is analogous to the lock on a door. The channel encryption mechanism (TKIP or CCMP/AES) is analogous to the door and hinges.

So, here we have an attack against hollow-core interior doors (give the door a good boot and your foot goes right through). Your choice of lock doesn’t affect your vulnerability to the attack, only the door you have installed.

Johannes Berg November 10, 2008 5:50 PM

The only good idea here is to use the TIDs to facilitate attacks, other than that it manages to attack TKIP in a rather unimportant way that’s trivial to defend against, and I gather not many people are still using WEP/TKIP if they actually care about security. Hardware acceleration for AES-CCMP has been on the market for some 6 or 7 years at least.

Todd November 10, 2008 5:51 PM


If you want to see this work, you can download the code from There is also a handy tutorial for tkiptun on the site.

Given the author’s previous success in this area, I think it’s fairly clear that it works.

Hellfire November 10, 2008 8:13 PM

Couple of thoughts –
1. I am not panicking since so many claimed cracks turn out to be nothing. (Elcomsoft using a GPU to crack WPA 100 times faster). This seems much more legit, since they seem to be following the proper channels and waiting to publish a paper rather than make wild claims.

  1. Hopefully hardware will upgrade faster this time. I still find things that don’t support WPA, let alone WPA2.

  2. Aircrack-ng gets this stuff so fast.

Billy November 11, 2008 1:04 AM


If you haven’t seen the paper yet, you should know better than to proliferate hype. Your voice carries too much weight to use it carelessly.

Alan (2) November 11, 2008 4:53 AM

@Davi Ottenheimer

“You could say the same about anything.”

Too true, even about your typical user. 🙂 But a hacker needing physical access makes it so much harder for him/her, and makes it easier to prove unauthorized access e.g. in court.

As has been mentioned above, I have also seen much older hardware still in use but limited to the first version of WPA or even WEP.

Alan November 11, 2008 7:29 AM

@Billy: Bruce did not express an opinion. In fact he included the disclaimer that he had not read the paper. But starting this conversation has led to clarification of some misinformation that is being circulated.

Shuo November 11, 2008 11:36 AM

Quote==Tews said. “You just need a short packet with hopefully not so much unknown bytes” such as a TCP/IP SYN packet or certain DNS queries.==Quote

Most APs for 802.11 access still allows DNS queries before the client authenticate itself. E.g. when you try to associate your laptop to an airport AP, when you see the greeting page, you are usually granted DNS access already.

Using that granted DNS access you can then generate some know DNS queries.

This would give you some known DNS packets. I guess this would cut down the 900 minute crack time by a lot.

dragonfrog November 12, 2008 10:45 AM

Shuo – you’re actually thinking of something else.

Most airport APs actually aren’t encrypted at all. You don’t need to crack anything to spoof DNS on those networks – just inject your responses.

These networks use a ‘captive portal’ webpage that just adds MAC addresses to an allowed list. It’s easily bypassed by snooping for MAC addresses of computers that are successfully browsing, and then changing your wireless NIC’s MAC address to the same one. As long as both computers have firewalls set up to simply ignore unexpected packets, rather than sending error messages that would reset the conversation, there shouldn’t even be any interference.

Depending on jurisdiction and details of the network, the above is of course probably illegal, and in any case is not something your mother would approve of. IANAL.

Leave a comment


Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via

Sidebar photo of Bruce Schneier by Joe MacInnis.