> WPA2 provides reliable security used in billions of Wi-Fi devices every day. What do you mean, "reliable", the Wi-Fi Alliance? I get it: If DEAUTH attack has

> WPA2 provides reliable security used in billions of Wi-Fi devices every day. What do you mean, "reliable", the Wi-Fi Alliance? I get it: If DEAUTH attack has been fixed by deploying 802.11w[0], provide the randomness is generated by a proper CSPRNG (unlike the stupid one from the appendix of the official spec!) with a high-quality entropy source (not system uptime in milliseconds!)[1], and that bruteforce-friendly WPS ("Protected" Setup) has been deactivated, finally KRACK attack has been patched from the both sides? In addition don't forget to disable TKIP and force CCMP[2]? This is another reason why (correctly-deployed) HTTPS must be pushed forward. Just imagine these Wireless Internet of Shit. Despite the PR and marketing blurbs in the article, I hope it's a good news and I sincerely hope the engineers and designers have a good insight of what's going on around cutting-edge modern cryptography this time, and also understand my points below. Hopefully things will go better. Even without these flaws, WPA's crypto is far from ideal under a modern perspective. The lack of Forward Secrecy is the greatest blunder of the protocol. Anyone can record all the data packets then decrypt them later if the passphrase is discovered. Designers at IEEE did realized the problem and they came up with an unnecessarily complicated handshake protocol to derive a session key every time you connect to an AP. But the handshake itself is ultimately still protected by the single passphrase! Coincidentally, the DEAUTH loophole enables attackers to pretend being the AP, kicking everyone out of the network and force them to redo handshakes for your capture and wiretap immediately (in case you never have a chance to get previous ones), combo! Hence the WPA-"Personal" is crap so you go to WPA-"Enterprise", precisely WPA-EPA, which is extremely complicated to configure with little benefits in terms of security (major advantages are accountability, authorization, etc though), as most OSes don't even check the root certificate by default. The only workaround I could recommended to people who need serious security over Wi-Fi, is to leave the existing WPA untouched and untrust, then installing a solid VPN on the gateway and require everyone to connect for LAN/WAN access. Real Solution is simple, exactly the same as how we fixed Transport Layer Security and HTTPS: Diffie-Hellman Key Exchange. The absence of DH may be justified by the low computational power in the early 2000s, but it can't be an excuse anymore. Just perform a DH before you transmit any real data, can't be easier, and no unnecessarily complicated handshake protocol required. You might still say, well, what about the Man-in-the-Middle? Sure, but cracking Wi-Fi would not be as simple as capturing packets and typing the passphrase in WireShark, period. Also works for public networks without passwords. In fact, interestingly, WPS REALLY DOES PERFORM THE DH to protect the main passphrase, in other words, for every single PIN-code you try to bruteforce, there's a DH exchange... The world is full of ironies. Even better, because a pre-shared key is already presented (the Wi-Fi "password"), the key itself can be used (and should only be used) to authenticate the DH, MITM problem solved, no user-experience changed, no internal PKI/CA needed, but strong cryptography, forward secrecy, and the only pre-requirement is a strong passphrase, which can be generated by EFF's Diceware[3] for all security-minded users. Wi-Fi, secured for the first time. It can be even better if the Diffie-Hellman is based on good crypto, something like X25519, with authenticated encryption like ChaCha20-Poly1305, with a modern key derivation function like Argon2 to stretch the passphrase to stronger key and avoid bruceforce attacks. And you can always use lightweight-equivalents (but not low-security version) to these cutting-edge algorithms if hardware constraints is an issue. BTW, this is what "ECDHE_PSK Cipher Suites"[4] in TLS is about: forward secrecy, high security with only a passphrase and no certificate, for your HTTPS, etc, it should be easy to use and widely used. But unfortunately nobody ever noticed them and LibreSSL even removed them due to the lack of interest and maintenance burden (contributes to security problems in the end). In fact you can just make WPA-EPA's TLS to use a ECDHE_PSK ciphersuit, and you can have "Enterprise" security with only a password, but nobody support this ciphersuit anyway... [0] https://en.wikipedia.org/wiki/Wi-Fi_deauthentication_attack https://en.wikipedia.org/wiki/Wi-Fi_deauthentication_attack https://en.wikipedia.org/wiki/IEEE_802.11w https://github.com/DanMcInerney/wifijammer Basically, the 802.11w defense is undeployable. Most clients and APs still have no support. Even if you control all the devices, 802.11w needs to be implemented by the device driver, but what a driver can do depends on the on-chip firmware, which has no support of it! And you know the firmware is proprietary and you can't do anything with it. If my memory is right, only two or three Wi-Fi families have 802.11w on Linux, and for hardware tinkers you are not disappointed, just as expected, it works best with ath9k, which is a family with official involvement in mainline driver development, and no on-chip firmware is used at all. You can enable 802.11w on LEDE if a supported chip is used, RTFM for instructions. You should only use "Optional", not "Mandatory", because of the above reasons. [1] Predicting, Decrypting, and Abusing WPA2/802.11 Group Keys https://media.ccc.de/v/33c3-8195-predicting_and_abusing_wpa2_802_11_group_keys (with Video) https://news.ycombinator.com/item?id=15478750 If you are using a Linux-based solution with newer kernels, like OpenWrt/LEDE, it's completely safe from these attacks, thanks to the improvements of /dev/random in newer kernel and kudos to hostapd's developers for using the correct randomness from the beginning. However, if the device uses a proprietary implementation, even w/ Linux, it's likely a wrong one, accounts for 30% of the market share I guess... (and what, you said firmware updates?) [2] All Your Biases Belong To Us: Breaking RC4 in WPA-TKIP and TLS https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/vanhoef https://www.youtube.com/watch?v=Et8E1Y9c2GM RC4, that's enough said. [3] EFF's New Wordlists for Random Passphrases https://www.eff.org/deeplinks/2016/07/new-wordlists-random-passphrases [4] ECDHE_PSK Cipher Suites for Transport Layer Security (TLS) https://tools.ietf.org/html/rfc5489