Vulnerabilities in the WPA3 Wi-Fi Security Protocol

Researchers have found several vulnerabilities in the WPA3 Wi-Fi security protocol:

The design flaws we discovered can be divided in two categories. The first category consists of downgrade attacks against WPA3-capable devices, and the second category consists of weaknesses in the Dragonfly handshake of WPA3, which in the Wi-Fi standard is better known as the Simultaneous Authentication of Equals (SAE) handshake. The discovered flaws can be abused to recover the password of the Wi-Fi network, launch resource consumption attacks, and force devices into using weaker security groups. All attacks are against home networks (i.e. WPA3-Personal), where one password is shared among all users.

News article. Research paper: "Dragonblood: A Security Analysis of WPA3's SAE Handshake":

Abstract: The WPA3 certification aims to secure Wi-Fi networks, and provides several advantages over its predecessor WPA2, such as protection against offline dictionary attacks and forward secrecy. Unfortunately, we show that WPA3 is affected by several design flaws,and analyze these flaws both theoretically and practically. Most prominently, we show that WPA3's Simultaneous Authentication of Equals (SAE) handshake, commonly known as Dragonfly, is affected by password partitioning attacks. These attacks resemble dictionary attacks and allow an adversary to recover the password by abusing timing or cache-based side-channel leaks. Our side-channel attacks target the protocol's password encoding method. For instance, our cache-based attack exploits SAE's hash-to-curve algorithm. The resulting attacks are efficient and low cost: brute-forcing all 8-character lowercase password requires less than 125$in Amazon EC2 instances. In light of ongoing standardization efforts on hash-to-curve, Password-Authenticated Key Exchanges (PAKEs), and Dragonfly as a TLS handshake, our findings are also of more general interest. Finally, we discuss how to mitigate our attacks in a backwards-compatible manner, and explain how minor changes to the protocol could have prevented most of our attack

Posted on April 15, 2019 at 2:00 PM • 22 Comments


David RudlingApril 15, 2019 4:33 PM


I briefly thought there was a light at the end of the tunnel on reading of the mitigations identified but then came to:-

" Surprisingly, when the CFRG was reviewing a minor variant of Dragonfly, they actually discussed these type of modifications ........ However, to our surprise, this change was
not incorporated into any of the Dragonfly variants."

Did someone at the NSA or similar really earn their bonus that time?

Very depressing.

MXApril 16, 2019 8:36 AM

Well, apparently it does mean that all wifi are broken. How should we launch a secure wifi then?

Clive RobinsonApril 16, 2019 9:40 AM

@ David Rudling,

Did someone at the NSA or similar really earn their bonus that time?

With "finese" obviously.

I've seen it happen so many times, it's not only not any longer a surprise, but I actively go looking for it in the notes of meetings in standards committees etc.

As I've remarked befor look out for the "Health and safety" argument, it's just like the "Think of the children argument" based at best on extream or fanciful imaginings of dire consequences that are "Statistical improbabilities" at best, or as our host has named them in the past "Security Theater". However the real point is the argument is designed to be "unarguable against" because if you challenge it they then trot out how evil you are because you want children to be injured, maimed, disfigured, abused, killed, etc, etc...

The best thing to do is make notes such that at future times you can just discredit them just as vociferously, and make very public their history as "agents of evil intent by a rouge nation state". It does not stop their little games but it does slow them down.

The thing is you can never win against such people because they live off of your tax dollars, they suffer absolutly no economic or other harm by trying it on repeatedly untill they get what they want. All you can do is "name and shame" and slow them down. But if you get to successful at lifting the corner of the carpet where they hide like roaches, expect them to come out fighting.

Keep your eye on White House national security adviser John Bolton, he is a thoroughly nasty example of their ilk. Who he is actually working for is difficult to tell, but it does not appear to be the current administration in anything but name. Every time I hear him speak, the thought occurs "What genocide is he plotting now", shortly followed by "And who is going to benift by it"...

TatütataApril 16, 2019 9:47 AM

The depressing thing about this study is that WPA is precisely the kind of standard, which due to past experience, is supposed to undergo intense scrutiny before being released in the wild.

If "they" can't get it right here, where can "they" then?

FaustusApril 16, 2019 10:12 AM

"The resulting attacks are efficient and low cost: brute-forcing all 8-character lowercase password requires less than 125$"

Isn't this a little deceptive as a standalone number? The domain of upper and lower case passwords of 8 characters is 2^8 times larger than lower. The domain of reasonable passwords (with numbers and symbols) of eight characters is about 3^8 times larger than the lowercase version. Make it a much more reasonable 10 character upper, lower, digit, symbol password and the domain is at least 3^8*75*75 approx= 37 million times larger.

There are efficiencies in cracking large sets of passwords but they are probably captured by the original $125 cost of 8 char lower. Since any reasonable person uses at least 10 characters and a full character set perhaps we should be pointing out the cost of brute forcing a reasonable password is probably well over $1 billion dollars?

BobApril 16, 2019 10:39 AM


1. Downgrade & Dictionary Attack Against WPA3-Transition

This is bruteforce/dictionary attack by forcing the WPA2 standard. This is exploitation of an existing WPA2 vulnerability. Long (>20 chars) password was already recommended because of this WPA2 vuln, and honestly, security will never be so good anywhere that short passwords become viable.

2. Security Group Downgrade Attack

Client-based. We're basically waiting on MS, Apple, and Google to fix this from what I can tell. We saw something similar with KRACK, though that really only affected Android from what I can recall.

3. Timing-Based Side-Channel Attack

Looks like a different form of brute force, this one based on time to process using older security methods that don't obfuscate time to process. Password length is probably the biggest factor here, though there may be some other confounding factors depending on the intricacies of the algorithms involved. I'm not an algorithms guy.

4. Cache-Based Side-Channel Attack

This one starts off with the phrase "When an adversary is able to observe memory access patterns on a victim's device..." Honestly, this one feels like a bit of a nothingburger. At the point that "an adversary is able to observe memory access patterns on a victim's device," that device and everything on it, including wi-fi credentials, is already pwned.

5. Denial-of-Service Attack

No confidentiality impact here. Potential for integrity impact in poorly planned implementations. High availability impact - essentially tricking the AP into using all its CPU power on garbage authentication attempts. Looks like limiting the amount of CPU usable for authentication attempts is a start, though that's still going to delay or prevent legitimate connections from being formed, it should keep the AP from getting deadlocked. This one's going to take some creativity on the part of the vendors. I still have the good fortune of not having to run anything mission-critical over wi-fi.

Clive RobinsonApril 16, 2019 11:17 AM

@ MX,

How should we launch a secure wifi then?

Well as you've not been able to do it so far, what makes you think you might be able to now?

The point is secure communications has three asspects you need to consider,

1, Message Content security.
2, Mesage Metadata security.
3, Underlying hardware/OS security.

The first can be done with the right forms of "end to end" encryption, only if the endpoints are secure.

The inherent way that WiFi protocols works means that unless you build some inyeresting network topology over the top of the WiFi and ethernet protocols the metadata can not be made secure, thus traffic analysis can be fairly easily acomplished by even a single person as an adversary.

As for hardware, OS and Application security, it's effectively non existant. So without some specialized precautions you end points will not be secure. So it does not realy matter how hard you try to make the WiFi asspect of things secure, you will fail to "end run attacks" via IO drivers below the OS kernel and the apps the OS supports that makes the plain text a user sees available to the adversary...

Yup nobody said it was easy, abd the idiom of the "weakest link" still holds sway and in this case it's the underlying end point securiry negating all the communications security.

Clive RobinsonApril 16, 2019 11:25 AM

@ Tatütata,

which due to past experience, is supposed to undergo intense scrutiny before being released in the wild.

And it is subject to intense scrutiny, but not for what you would hope. The intense scrutiny is so that some standards committee does not SNAFU the pitch of the IC's "collect it all" by accidentally or by design.

I've seen it rather to often to doubt in any way it exists.

Any way I hear the rattle of the dinner trolly, hopefully they have my order right and not the usuall inedible fodder they serve the other unfortunates under going medical care...

Clive RobinsonApril 16, 2019 11:41 AM

@ Bob,

At the point that "an adversary is able to observe memory access patterns on a victim's device," that device and everything on it, including wi-fi credentials, is already pwned.

Cache usually alow timings of activities in memoryvto become visable to the network simply by sending the target device data.

You don't have to actually see either the contents of the memory or the addresses at which it's stored for cache based attacks to leak data.

Look on it as an attack against meta-operations not data/addresses or meta-data/addresses.

You can use such attacks to synchronize timing for other active fault injection attacks. It's a subject that does not get much talked about, but is a very real threat. In essence if you know the code being executed it has a timing signiture against which it can not only be identified, but it's future actions identified. If you then cause an error or exception at an appropriate time you can in effect break the atomic nature of blocks of code which can open other vulnerabilities that can be exploited.

Such injection attacks can work against "formaly verified" code because it can cause a change of state that top level checking does not catch. Thus it's an attack method that "bubbles up" the computing stack.

Ross SniderApril 16, 2019 12:54 PM

I made this comment in 2018 on this blog as the standards were coming to a closure:

The use of the dragonfly PAKE has significant disadvantages:
1. There are known timing side channels on the protocol which already defeat the password protection.
2. There are several known active attacks on the protocol which already defeat the password protection, some under the assumption of non-robust implementations and others unconditional properties of the protocol.
3. The implication of the protocol is that passwords must be stored in a format which make them brute forceable, again defeating the password protection.
4. The parameter negotiation can be used to force malicious parameters, which is even more dangerous given how the protocol can be initiated by any side.
5. The implementation of the crypto is fragile (easy to exclude checks which subvert the security of the scheme). It is not clear that the specification includes all checks necessary for a robust implementation.

The designer of Dragonfly came into the comments and spread more FUD about it:

Anyway, all of this was predicted, and there was even a fairly concerned effort by cryptographers to point out in public the poor choices of the committee and NSA-supported position.

RealFakeNewsApril 16, 2019 5:29 PM

I'm sure it was discussed right here on this blog when it was first announced, that WPA3 is insecure.

I'm sure it was also mentioned how they seemed to almost deliberately miss the point with WiFi security when inventing any of these schemes.

Why don't they use tried-and-true PKI with AES-256 and be done, instead of this nonsense?

Clive RobinsonApril 16, 2019 6:45 PM

@ David Rudling,

Did someone at the NSA or similar really earn their bonus that time?

Some definitely think so and have named a name who works for the NSA, and point blankly demands the persons removal from post. With an involved "J'Accuse" attached. Whilst not quite upto that published by Emile Zola, it does make the case refrencing back to other NSA employee behaviour and misdeeds with respect the CS-DRBG they back doored...

It's taken me a little longer to find than I thought it would...

You and others might find it interesting reading...

I would have found it sooner but Google has just screwed the pooch re EU and the GDPR data protection regulations in a totally bat shit crazy way. So I've tried using another search engine with which I'm not familliar, and I suspect my mutterings although muted somewhat were not as temperate as they could be :$ However having purged Google, I will put in the effort to get the best from the new search engine...

But... It turns out @Ross Snider posted a link back to an earlier thread on this blog and the link I was looking for was on that very page...

DroneApril 16, 2019 10:58 PM

Excerpting from this informative April 10th 2019 ZDNet piece:

"In total, five vulnerabilities are part of the Dragonblood ensemble -- a denial of service attack, two downgrade attacks, and two side-channel information leaks. While the denial of service attack is somewhat unimportant as it only leads to crashing WPA3-compatible access points, the other four are the ones that can be used to recover user passwords.


Dargonblood [sic] also impacts EAP-pwd: Besides WPA3, researchers said the Dragonblood vulnerabilities also impact the EAP-pwd (Extensible Authentication Protocol) that is supported in the previous WPA and WPA2 WiFi authentication standards.


The two researchers didn't publish details how the Dragonblood vulnerabilities impact EAP-pwd because the patching process is still in progress. They did, however, publish tools that can be used to discover if WPA3-capable devices are vulnerbale [sic] to any of the major Dragonblood flaws.


Fixes for WPA3 are available: On the other hand, the WiFi Alliance announced today a security update for the WPA3 standard following Vanhoef and Ronen's public disclosure of the Dragonblood flaws. "These issues can all be mitigated through software updates without any impact on devices' ability to work well together," the WiFi Alliance said today in a press release. Vendors of WiFi products will now have to integrate these changes into their products via firmware updates.


Vanhoef is the same security researcher who in the fall of 2017 disclosed the KRACK attack on the WiFi WPA2 standard, which was the main reason the WiFi Alliance developed WPA3 in the first place."

DaveApril 16, 2019 11:13 PM

>Did someone at the NSA or similar really earn their bonus that time?

It had nothing to do with the NSA. The author of Dragonfly is notoriously difficult to deal with and prefers to shout down any feedback or criticism rather than responding to it and fixing things. Even before that point some within the IETF declined to review his proposal because it just wasn't worth the headache of having to deal with him so it barely got any review.

There's a lot more to it than that but the blame is squarely at the foot of the Dragonfly author no need for any NSA conspiracy.

I haven't mentioned a name because he kibozes the net for any mention of himself and pops up in the discussion to argue with everyone in sight. I assume he'll turn up here at some point just listen for the shouting.

fishApril 16, 2019 11:16 PM

@Clive Robinson

Which search engine is this? I find that Google used to be by far the best (but now they merge different search terms in ways that make research quite difficult), with Bing being a close second. Pretty much anything but DuckDuckGo (whose results are downright awful)...

Clive RobinsonApril 17, 2019 10:47 PM

@ fish,

The reason for dropping Google is their now absolute insistance that you be "data raped" by them.

Prior to this you used to be able to use Google with Javascript and cookies turned off.

Yes unless you went through a VPN they could still track you but it was not as invasive.

But also working with broadband mobile Google sending several packets for each key you press, takes a very big chunk of a dataplan for absolutly no good reason. Also it alows them to do biometric identification by both your typing cadence and any spelling error patterns you might correct...

As Microsoft are just as bad if not worse these days, their offering is also compleatly dissed.

Which leaves DuckDuck... Yes it's not very good but Google and other Silicon Vally and Seattle based organisations have made it absolutly clear that data rape is their primary objrctive, and that they fully intend to kill off the purpose of the EU GDPR, I'm voting with my feet and they can go take a flying one at each other.

Hopefully a more EU legislation search engine will arise, and thus break the US cartel.

fishApril 18, 2019 8:47 PM

@Clive Robinson

I use Tor to reduce the tracking done by Google (yes, they block it sometimes, which is a shame). With the security slider set to high, JavaScript is also disabled which reduces the risk of biometric fingerprinting ("real-time search" or whatever they call it).

Why not use StartPage? It uses a syndicated feed to Google so the search quality is pretty good (much better than DDG), but doesn't track you.

Leave a comment

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

Sidebar photo of Bruce Schneier by Joe MacInnis.

Schneier on Security is a personal website. Opinions expressed are not necessarily those of IBM Resilient.