Wi-Fi Security: WPA2, WPA3, and the 4-Way Handshake

What Wi-Fi security protects against

Because Wi-Fi is a shared radio medium, anyone within range can receive every frame a network sends, whether or not they're authorized to join it — so confidentiality and authentication have to be built into the Wi-Fi standard itself rather than assumed from physical access. The original WEP standard tried to do this with RC4 encryption and a static key, but its key-reuse flaws make it crackable in minutes with modern tools, and it should never be used today. WPA followed as a stopgap, and WPA2 (certified 2004) became the long-standing baseline, using AES-CCMP encryption and the 4-way handshake covered below. WPA3 (certified 2018) is the current standard, replacing WPA2's weakest step — covered later in this lesson — while keeping the same AES-based encryption for the data itself.

WPA2 and the 4-way handshake

In WPA2-Personal, the client and AP both already know a shared password and the network's SSID. Both sides independently derive a Pairwise Master Key (PMK) from these using PBKDF2, without transmitting anything. The 4-way handshake then derives a unique Pairwise Transient Key (PTK) for this specific session: the AP sends a random ANonce (message 1), the client replies with its own SNonce and a Message Integrity Code proving it holds the correct PMK (message 2), the AP verifies this and sends the Group Temporal Key used for broadcast traffic (message 3), and the client confirms installation (message 4). After these four messages, the PTK encrypts all unicast traffic for the rest of the session.

The offline dictionary attack problem

All four handshake messages are sent in the clear — there's no shared key yet to encrypt them with. This means anyone within radio range can passively capture a complete copy of the handshake without ever interacting with the client or AP. Because the handshake's Message Integrity Code can be recomputed entirely from public values (the captured nonces and MAC addresses) plus any candidate password, an attacker can test password guesses on their own hardware indefinitely, with no further contact with the network and nothing for the AP to rate-limit or lock out. A long, random password makes this infeasible in practice, but a short or common one can eventually be recovered — this is WPA2-Personal's core structural weakness, not a bug in any particular implementation.

WPA3 and SAE

WPA3-Personal replaces WPA2's PSK-derived first step with SAE (Simultaneous Authentication of Equals), a Diffie-Hellman-based exchange also known as the Dragonfly handshake. Instead of deriving a key purely from values an eavesdropper can passively capture, SAE requires a live, interactive exchange with the AP to derive each session's key — so an attacker who captures the exchange still can't test password guesses offline, because every guess would require its own real, rate-limitable round trip with the AP. SAE also provides forward secrecy: even if the password is later discovered, traffic from past sessions captured earlier still can't be decrypted, since each session's key was never purely a function of the password alone.

Interactive WPA2 handshake and the WPA3 fix

Step through a complete WPA2 4-way handshake message by message, then watch a passive eavesdropper use a captured copy of it to test passwords entirely offline — and see exactly what WPA3's SAE changes to close that gap.

Personal vs. Enterprise authentication

Everything above describes Personal mode (WPA2-Personal or WPA3-Personal), identified by a single shared password used by every device on the network — appropriate for homes and small offices, where issuing individual credentials isn't practical. Enterprise mode instead authenticates each user individually against a backend RADIUS server using 802.1X, so every device gets its own credentials (and its own unique session keys) rather than sharing one password across the whole network — letting a compromised or departing user's access be revoked individually, without having to change a password shared by everyone else. WPA3-Enterprise also adds an optional 192-bit security suite with stronger cryptographic algorithms throughout, intended for higher-security government and enterprise deployments.

Inspect Wi-Fi security evidence

A monitor-mode-capable wireless adapter can capture a 4-way handshake directly off the air during a client's association — the basis for every WPA2 password-recovery tool, and for legitimate password-strength auditing on networks you're authorized to test.

Guided handshake practice

Work through why password length matters so much more for WPA2-Personal than it does for, say, an online login form. An online login form can lock an account after a handful of failed attempts, making brute-forcing impractical regardless of password length. A captured WPA2 handshake has no such limit: the attacker's guessing happens entirely on their own hardware, so the only real defense is making the search space itself infeasibly large — a long, high-entropy passphrase (16+ random characters, or a multi-word passphrase) resists this kind of attack even though the exact same captured handshake would be available to attack either way.

Troubleshoot Wi-Fi security

1. Confirm both the client and AP are actually configured for the same WPA version and cipher — a client that only supports WPA2 cannot connect to an AP configured for WPA3-only, and the resulting failure often looks like a wrong-password error instead of a compatibility mismatch.
2. Check for a "WPA3 transition mode" AP broadcasting both WPA2 and WPA3 simultaneously — while this maximizes compatibility, it reintroduces WPA2's offline dictionary-attack surface for any client (or attacker) that connects via the WPA2 side.
3. Rule out a simple typo or case-sensitivity issue in the password before assuming a security or configuration problem — Wi-Fi passwords are case-sensitive and this remains the most common cause of authentication failures.
4. If 802.1X/Enterprise authentication fails, check the RADIUS server's logs directly rather than the client, since Enterprise failures (expired certificates, misconfigured EAP methods) usually surface clearly server-side but only as a generic failure on the client.
5. Distinguish an authentication failure (wrong password or incompatible security settings, happens before any IP configuration) from a DHCP or IP-layer failure (associates and authenticates fine but can't get an address) — they point to completely different layers of the connection process.

Knowledge check and summary

Pro deep dive