Wi-Fi Security and 802.1X

TL;DR: WPA2-Personal derives keys from a shared passphrase, so anyone who captures a handshake can guess the passphrase offline. WPA3-Personal replaces that with SAE, which resists offline guessing, but transition mode lets attackers downgrade capable clients and early implementations leaked through side channels (Dragonblood). KRACK (2017) showed WPA2's 4-way handshake could be tricked into reusing nonces, a protocol flaw no password strength fixes. Enterprise Wi-Fi uses 802.1X: EAP between the device and a RADIUS server, through the access point. Its security rests on one client-side check: does the device verify the server's certificate and name? Without it, an evil twin collects credentials. The baseline is EAP-TLS with device certificates from a private CA, WPA3 with protected management frames, and 802.1X on wired ports too.

Personal and Enterprise modes

Wi-Fi security comes in two families, and the threats differ.

The practical summary: a shared passphrase is a shared secret among everyone who has ever been told it, so Personal mode suits homes and isolated guest networks, and Enterprise mode suits anything an organisation must control.

The 4-way handshake and KRACK

After authentication, a client and access point run a 4-way handshake to derive fresh session keys from a pairwise master key and exchanged nonces. In 2017 Mathy Vanhoef showed that an attacker positioned between them could replay the third message of that handshake, making the client reinstall a key it was already using and reset its nonce and replay counters. Nonce reuse breaks the encryption: with CCMP the attacker can decrypt packets, and with TKIP or GCMP they can also forge them. Some Linux and Android clients (wpa_supplicant 2.4 and later, Android 6.0 and later) were worse, reinstalling an all-zero key. The attacks, known as KRACK (CVE-2017-13077 and related), were presented at ACM CCS in November 2017.

KRACK did not reveal passwords, and no password strength helped against it. It was a flaw in the protocol's state machine, fixed by patching clients and access points to refuse reinstalling an installed key.

WPA3 and its limits

WPA3-Personal replaces the passphrase-derived key with SAE (Simultaneous Authentication of Equals), a password-authenticated key exchange. An attacker who records a handshake learns nothing they can test guesses against offline; each guess requires a live interaction with the network. SAE also gives forward secrecy: learning the password later does not decrypt recorded sessions. WPA3 makes protected management frames (PMF) mandatory, which stops attackers forging the de-authentication frames once used to knock clients off and capture handshakes. WPA3 became mandatory for new Wi-Fi CERTIFIED devices in July 2020, and the 6 GHz band of Wi-Fi 6E requires WPA3 with PMF; there is no WPA2 fallback there.

Its early life was not clean. The Dragonblood research (April 2019) found two classes of problem:

• Downgrade in transition mode. A network that accepts both WPA2 and WPA3 on the same name lets an attacker run a fake WPA2-only access point, so a WPA3-capable client falls back to WPA2 and exposes a handshake for offline guessing.
• Side channels in the password encoding. Timing and cache behaviour while converting the password into a group element leaked information that allowed offline guessing (CVE-2019-9494 among others). The fix, now standard, is a constant-time method known as hash-to-element (H2E).

The lessons: use WPA3-only network names for devices that support it, keep transition mode only where legacy devices force it, and require H2E.

Enterprise Wi-Fi: 802.1X and EAP

802.1X has three roles: the supplicant (the device), the authenticator (the access point or switch, which blocks traffic until authentication succeeds) and the authentication server (RADIUS). The device and the RADIUS server run an EAP method through the access point; when it succeeds, the server gives the access point keying material for that session.

The decisive setting is on the client: verify the server's identity. A profile that pins the CA that issued the RADIUS server's certificate and the server's name, and does not let users click past a warning, turns an evil twin into a failed connection. A profile that accepts any certificate makes PEAP's tunnel protect the attacker.

Two developments push organisations towards EAP-TLS. Windows Credential Guard, on by default for eligible Windows 11 22H2 and later Enterprise and Education devices, blocks single sign-on with MSCHAPv2-based methods, so PEAP-MSCHAPv2 users are prompted for passwords; Microsoft recommends moving to certificate-based PEAP-TLS or EAP-TLS. And public certificate authorities are moving to hierarchies dedicated to TLS servers, so device and RADIUS certificates for 802.1X should come from a private CA the organisation controls.

SSID confusion

In 2024 researchers described SSID confusion (CVE-2023-52424): in some configurations the network name is not authenticated as part of the handshake, so a client can be steered onto a different network that shares the same credentials, for example from a trusted network to an untrusted one with the same password or RADIUS backend. Some clients turn off their VPN on networks they consider trusted, which makes the confusion worse. The defence is not to share credentials across networks of different trust, and to use 802.1X configurations that tie the network to its server identity.

The wired side

An attacker who can plug into a meeting-room port bypasses Wi-Fi entirely. The same ideas apply to wired networks: 802.1X on access ports, with MAC authentication bypass reserved for an inventoried class of devices such as printers that cannot run a supplicant; DHCP snooping, dynamic ARP inspection and router advertisement guard on switches so a plugged-in device cannot impersonate the gateway; and client isolation on wireless networks so devices on the same network cannot reach each other directly. See attacker positions on the network.

Worked example: migrating 5,000 laptops off PEAP-MSCHAPv2

A company's 5,000 Windows 11 laptops use PEAP-MSCHAPv2. After a move to 22H2 with Credential Guard on, users are prompted for passwords every time they connect, and help desk tickets rise. A review also finds that some profiles do not pin the RADIUS server's name and CA.

The result removes passwords from the air, makes an evil twin useless because devices only trust the pinned server, and gives each device an identity that can be revoked individually.

Misconceptions interviewers listen for

• "A strong WPA2 password stops KRACK." KRACK was a protocol state bug; patches fixed it, passwords did not.
• "WPA3 makes evil twins impossible." SAE protects the password in Personal mode; in Enterprise mode the client still has to validate the server.
• "PEAP is safe because it runs inside TLS." Only if the client verifies the server's certificate and name.
• "A public CA certificate on the RADIUS server is fine." Unless the name is pinned, any public certificate could be presented; use a private CA and pin it.

How this shows up in interviews

Expect "how would you secure office Wi-Fi?", "what was KRACK?", "WPA2 versus WPA3?" and "what is an evil twin and how do you stop it?". Strong answers separate the passphrase problem from the protocol problem, explain that Enterprise security is decided by server validation on the client, and propose EAP-TLS from a private CA with WPA3 and PMF, plus 802.1X on wired ports.

Say it in 30 seconds: "WPA2-Personal's shared passphrase can be attacked offline from a captured handshake; WPA3's SAE fixes that, though transition mode allows downgrade and early versions had side channels. KRACK showed WPA2's handshake could be forced to reuse nonces, fixed by patches, not passwords. For organisations I use 802.1X with EAP-TLS device certificates from a private CA, profiles that pin the RADIUS server's name and CA, WPA3 with protected management frames, and 802.1X plus anti-spoofing on wired ports, because enterprise Wi-Fi is only as strong as the client's server check."