
Serious flaws leave WPA3 vulnerable to hacks that steal Wi-Fi passwords - eaguyhn
https://arstechnica.com/information-technology/2019/04/serious-flaws-leave-wpa3-vulnerable-to-hacks-that-steal-wi-fi-passwords/
======
zamadatix
Downgrade attacks:

WPA3 has a transitional mode which allows legacy WPA2 clients to connect. In
this mode legacy WPA2 security issues are still present. Is this really a
discovery or a given? How is WPA3 supposed to protect against it without
requiring either WPA2 clients to be upgraded to support WPA3 security fixes
(in which case you don't need WPA2 support anymore anyways) or without
dropping support for transitional mode? 802.11w fixes much of this but WPA2
didn't mandate support for this which is one of the big reasons WPA3 is so
much better.

Dragonfly downgrade:

"The hack can force the access point to use a different curve, presumably one
that’s weaker." note: not "The hack can force the access point to use a
different curve, one that’s weak.".

Side channel leaks:

Are failures in implementations not WPA3. If you're allowing local timing
attacks while generating your keys it doesn't really matter what protocol
you're using you've just failed. A real discovery of things in the wild that
need to be fixed but nothing to do with the security of the specification.

Denial of service:

It's far more effective and simple to DoS the air than to DoS the APs CPU
anyways. Always has been always will be. Besides, would you rather it be
faster and have the AP expose side channel attacks instead?

"dragonblood":

Makes me think some researchers were out for their 5 minutes of fame with a
cool sounding "vulnerability". To be a little less critical the researches
discovered in-the-wild side channel attacks on popular client implementations
of the crypto (but that doesn't sound as cool as "serious flaws leave WPA3
vulnerable".

~~~
blitmap
Preface: I am not at all an expert on WiFi

In WPA2 you can send deauthentication "frames" to clients to get them to
disconnect from the access point. Later I was told these "control frames" can
now be encrypted, with an extension/modification to WPA2 supported in the
better consumer wireless routers like Linksys?

In response to your Denial of Service point: Does WPA3 make it harder to
disconnect clients? (or are you talking about simply overwhelming the airspace
with traffic/interference/jamming?)

~~~
sandworm101
There is only so much effort one can put into denial of service attacks in
wireless. The fact that this involves radio frequencies means there is always
a nuclear option: massive broadcasts of white noise. There is no way for wifi
devices to adapt to such an attack. So the fact that some denial attacks can
happen using exploits is moot. If the attacker really wants to hold your
network down he isn't going to bother with tricky packets. He is going to jam
the entire spectrum. Whether you are running WEP or some bleeding edge WPA5.7
implementation won't matter if all anyone can hear is white noise.

~~~
mschuster91
Yeah but if you're a sleazy hotel chain that simply wants people to use their
crappy expensive wifi instead of personal hotspots then you can't use the
"nuclear option" as the white noise will also fuck up _your_ network.

This is the type of attack that is being defended against here, not white-
noise bombs.

------
penagwin
For some reason I'm surprised we've had so many issues with Wi-Fi security.

I don't know if it was addressed in WPA3 (or if it would be addressed there),
but my understanding is that a good chunk of the protocol isn't authenticated
at all, such as the de-auth packets.

In a world with growing HTTPS support, OpenVPN, WireGuard, etc. and we can't
secure a wifi network with a shared key?

~~~
uuddlrlrbas
The reason we have had so many problems is because these "standards" are not
vetted by third-parties and therefore not allowed to test the security of
these standards. The Alliance is a closed members-only committee, so yeah I
don't doubt we will keep seeing these issues crop up.

~~~
zamadatix
I'm not going to get into the ideological debate of if the standards process
is open enough or not but let me pose this: Is it not more likely the fact
WPA2 was ratified in 2004 that it continues to be of questionable security to
utilize in 2019?

~~~
benchaney
No, because:

1\. WPA3, which has only recently been created, is riddled with issues.

2\. Many things much older than WPA2 are still used today without major issues
e.g. AES and RSA.

The idea that standards processes aught to be open is not a ideological debate
anymore. At this point it is a simple truth backed by overwhelming empirical
evidence.

~~~
zamadatix
The process not being open != The process should have happened sooner

In regards to 2 I disagree, see tls 1.0 as an example. Also aes isn't a
protocol, apples to oranges.

------
rdl
My dream is to eliminate PSK from all the networks I care about/am responsible
for, but it's really challenging to deploy 802.1X in anything but a fully
managed enterprise (and also hard when you also have random other IOT/etc.
type devices; usually the "important" ones you can just put onto wired
network, and the unimportant ones go onto dedicated psk, but it's still a
pain.

Still hate it all less than captive portals (which I hate so so much), but
it's pretty annoying.

~~~
xoa
Agreed all around, it'd be really nice if there were better general standards
for friendly ways to deploy and utilize 802.1x. IOT is definitely a big hold
up there, support is quite spotty even amongst new major device manufacturers.
I recently was asked to deploy a bunch of Nest smoke alarms at a business for
example (they are genuinely nice, and the testing I've seen indicate their
dual wavelength photoelectric sensors do a very good job), and they don't
support it. But even outside of IOT I'm quite surprised sometimes by
mainstream devices that make it more of an effort then it needs to be, such as
Chromebooks. I was surprised mainly because one place user/pass auth for WiFi
isn't at all uncommon is colleges, and I'd have assumed students there were a
significant enough general market to be worth more attention. On a Mac 802.1x
is all a single flow at the simplest level, select the network, enter the
credentials, it'll ask about the cert if it's self-signed, and that's it.
Compare to the Chromebook procedure [1], it's not like it's horribly involved
but why the whole separate cert procedure?

Granted, authentication in general remains a lot of spaghetti across the
entire industry. I don't think there is a lot of relief overall on the
horizon, though at least in some areas like with WebAuthn there is hopeful
progress. Maybe progress in separate areas will ultimately make a foundation
that can be further expanded.

1:
[https://support.google.com/chromebook/answer/1047420?hl=en](https://support.google.com/chromebook/answer/1047420?hl=en)

------
robocat
Aside: “A valid SSID is 0-32 octets with arbitrary contents”

An SSID is up to 16 bytes of arbitrary data e.g. 16 nulls is a valid SSID - I
wonder how many UI flaws (or security flaws) result from that decision...

Why wouldn’t WPA3 introduce sane limitations on SSIDs?

~~~
gruez
>e.g. 16 nulls is a valid SSID - I wonder how many UI flaws (or security
flaws) result from that decision...

How can you exploit this? If you put in null bytes, then in all likelyhood it
will get truncated early. It's not going to cause an overflow or anything.

~~~
penagwin
This is just a "maybe" idea. If there's any clients that crash when not
expecting the nulls then you may be able to crash all effected devices within
the area.

Depending on how hard they crash, this might be generally affective maybe.

------
coldacid
Why can't a Wi-Fi encryption standard be developed in the open and added to
IEEE 802.11 as another annex? Or at least what's to keep people like us from
making our own standard in the open and implement it in our own systems at
least?

------
dboreham
The paper underlying this article :
[https://papers.mathyvanhoef.com/dragonblood.pdf](https://papers.mathyvanhoef.com/dragonblood.pdf)

