Wireless Security

Wi-Fi Standards and the 802.11 Family

IEEE Names vs Wi-Fi Generation Names

Wi-Fi runs on the IEEE 802.11 family of standards. Each successive amendment pushes throughput, range, and efficiency further while largely reusing the security mechanisms layered on top.

For most of Wi-Fi's history the standards carried IEEE's alphabet-soup names directly. In October 2018 the Wi-Fi Alliance introduced a simpler generational naming scheme so consumers didn't have to parse letter suffixes. Both naming conventions still show up in vendor documentation and device settings, so it helps to know they refer to the same underlying standards.

Security Runs on a Separate Layer

None of these amendments changed what security protocol runs on top of them. The 802.11 standard defines how frames get transmitted over the air; WEP, WPA, WPA2, and WPA3 are the separate authentication and encryption layer bolted onto that transmission standard.

A network running the newest 802.11ax hardware can still be configured with a weak or outdated security protocol, and a network on older 802.11n hardware can run WPA3 if the access point supports it. Throughput generation and security generation are independent axes, and conflating them is a common misunderstanding worth clearing up before going further.

What This Means for a Security Analyst

The practical takeaway from the standards lineage is narrower than the marketing version: newer 802.11 amendments generally ship with better default security postures baked into vendor firmware, wider adoption of Protected Management Frames, and less legacy fallback to weaker protocols for backward compatibility.

But the standard itself is a transport and performance spec, not a security guarantee. The rest of this chapter is about the layer that actually determines whether a wireless network can be trusted.

From WEP to WPA3: An Evolution of Failures

WEP (1997): The Original Failure

WEP (Wired Equivalent Privacy), introduced with the original 802.11 standard in 1997, was the first attempt at securing wireless traffic. It failed for reasons worth understanding, because the same category of mistake keeps recurring in security engineering: reusing a small, predictable value in a cryptographic scheme that assumes uniqueness.

WEP used the RC4 stream cipher combined with a 24-bit Initialization Vector (IV) prepended to the key for every packet. Twenty-four bits gives only about 16.7 million possible values, and on a busy network that space gets exhausted and IVs start repeating within hours. Once an IV repeats, an attacker who has captured enough traffic can use statistical techniques against the reused keystream to recover the WEP key entirely, without ever brute-forcing it.

WEP's failure wasn't a minor implementation bug, it was a structural flaw in how the protocol handled key material. That made WEP crackable by anyone with free tooling and enough patience.

WPA (2003): A Stopgap on the Same Cipher

WPA (Wi-Fi Protected Access) arrived in 2003 as a stopgap, implementing most of the emerging 802.11i security standard while still running on the same aging RC4 cipher so it could be pushed out as a firmware update to existing WEP hardware.

Its key improvement was the Temporal Key Integrity Protocol (TKIP), which generated a new per-packet key instead of reusing one static key across the network, and replaced WEP's broken integrity check with the Michael Message Integrity Check. TKIP closed WEP's IV reuse problem, but because it was still built on RC4, it inherited enough of that cipher's weaknesses that TKIP itself was eventually shown to be crackable given sufficient time and specific attack conditions.

WPA2 (2004): A Structurally Sound Baseline

WPA2, standardized in 2004, is where wireless security matured into something structurally sound. WPA2 made support for CCMP (Counter Mode with Cipher Block Chaining Message Authentication Code Protocol) mandatory, an AES-based encryption mode that handles both confidentiality and data integrity in a single pass, replacing RC4 entirely.

This is a meaningfully different cryptographic foundation than WEP or WPA, and it's the reason WPA2-AES-CCMP remained the baseline enterprise and home standard for well over a decade. WPA2's actual weak point, as the next section covers, was never the cipher itself but the handshake used to derive session keys from a pre-shared password.

WPA3 (2018): Hardening Authentication, Not the Cipher

WPA3, certified by the Wi-Fi Alliance starting in 2018, is not a response to a broken cipher the way WPA2 was a response to WEP. AES-CCMP remains sound.

WPA3's changes target the authentication step that precedes encryption: it replaces WPA2's pre-shared key exchange with SAE (Simultaneous Authentication of Equals), adds mandatory Protected Management Frames to stop certain deauthentication and forgery attacks, and introduces an Enhanced Open mode for public networks that encrypts traffic even without a shared password.

The trajectory across all four generations is consistent: each protocol fixed the specific class of attack that broke its predecessor, and each fix narrowed, rather than eliminated, the attack surface for the next one.

The WPA2 4-Way Handshake and Offline Cracking

How the 4-Way Handshake Works

WPA2-Personal networks are secured with a pre-shared key (PSK), the passphrase you type in once. That passphrase is never transmitted over the air, and it isn't the key that actually encrypts traffic either.

Instead, when a client joins the network, the client and access point run a 4-way handshake that proves both sides know the PSK and derives a fresh session key, without ever sending the PSK or the resulting key itself across the air. The exchange runs in a fixed order:

1. Messages 1 and 2 confirm the shared PMK. Both sides establish that they are working from the same Pairwise Master Key (PMK), derived from the PSK plus the network's SSID.
2. Messages 3 and 4 install the session keys. The exchange installs the Pairwise Transient Key (PTK), which protects the actual data traffic, along with a Group Temporal Key (GTK) used for broadcast and multicast traffic.

Why Offline Cracking Works

The handshake is a genuinely well-designed piece of engineering: it lets two parties confirm shared knowledge of a secret and derive a fresh, unique session key without exposing that secret on the wire. But it created a different kind of exposure.

An attacker within range can passively capture the four handshake frames, either by waiting for a client to connect naturally or by forcing a reconnection with a deauthentication frame, and then take that capture offline. Because the handshake's messages are mathematically tied to the PMK, an attacker can try candidate passphrases against the captured handshake without ever touching the live network again, checking each guess against the captured frames until one produces a match.

This is why WPA2-Personal's real-world security depends almost entirely on passphrase strength rather than on the protocol itself. A short or dictionary-based passphrase can be recovered from a captured handshake in a reasonable amount of time using GPU-accelerated cracking or precomputed rainbow tables keyed to common SSIDs.

A long, high-entropy passphrase makes the same offline attack computationally infeasible, because the search space becomes too large regardless of how fast the attacker can guess. The handshake itself isn't the weakness; the passphrase feeding it usually is.

KRACK (2017): A Protocol-Level Flaw

The handshake did eventually have a genuine protocol-level flaw, disclosed in 2017 as KRACK (Key Reinstallation Attack). Under WPA2's design, a supplicant is expected to accept a retransmission of message three of the handshake, which happens legitimately when message four gets lost.

Researchers showed that a man-in-the-middle attacker could deliberately block message four and force a retransmission of message three, causing the client to reinstall a key it had already installed and, critically, reset the nonce counter used to prevent packet replay. That nonce reset let an attacker replay, decrypt, or forge frames without ever recovering the passphrase at all.

KRACK affected the handshake's implementation logic across effectively the entire WPA2 ecosystem and was fixed through vendor patches that made clients reject key reinstallation rather than accept it silently, not through a redesign of the passphrase-cracking exposure described above. The two issues are different: offline dictionary cracking targets a weak password; KRACK targeted a flaw in the protocol logic itself, independent of password strength.

WPA3's SAE Improvement

Live Guessing Instead of Offline Capture

WPA3-Personal replaces WPA2's PSK exchange with SAE, Simultaneous Authentication of Equals, based on the Dragonfly key exchange protocol. The core design change is that SAE requires an active, live protocol exchange with the access point for every single password guess.

Where WPA2's handshake could be captured once and then attacked entirely offline at whatever speed the attacker's hardware allowed, SAE forces each guess through a real-time interaction with the network. An attacker cannot passively capture a SAE exchange and walk away to brute-force it on a GPU cluster, because there's no static handshake transcript that maps cleanly to password guesses the way WPA2's did.

This matters most for weak passwords. Under WPA2, a captured handshake plus a weak passphrase equals a fast compromise. Under WPA3's SAE, the same weak passphrase is far more resistant to compromise because every guess costs the attacker a live network round-trip rather than an offline computation, and a network can rate-limit or detect an abnormal volume of live authentication attempts in a way it never could detect an offline dictionary run happening on someone's laptop miles away.

Forward Secrecy

SAE also delivers forward secrecy, a property WPA2's PSK exchange lacked. Under WPA2, if an attacker later obtains the PSK, they can decrypt previously captured traffic, because the session keys for every past connection were deterministically derivable from that same PSK plus captured handshake data.

Under SAE, each session's keys are derived through a fresh key exchange, so learning the password later does not retroactively unlock previously recorded encrypted sessions. That's a meaningful shift: WPA2 handshake captures represent standing risk indefinitely; SAE captures do not carry the same retroactive exposure.

Dragonblood (2019): Implementation Weaknesses

WPA3 is not a cryptographic silver bullet, and it's worth being accurate about that rather than overselling it. Security researchers, notably in the Dragonblood research published in 2019, identified real implementation and side-channel weaknesses in early SAE deployments, including timing and cache-based side channels that could leak information usable in password-partitioning attacks, and denial-of-service concerns around the protocol's anti-clogging mechanisms.

Those findings led to Wi-Fi Alliance guidance and vendor patches, and they're a useful reminder that a stronger protocol design still depends on correct implementation. SAE's structural improvement over WPA2's PSK exchange, resistance to offline dictionary attacks and forward secrecy, stands regardless; specific implementations still need to be kept patched.

Rogue Access Points and Evil Twin Attacks

Rogue AP vs Evil Twin

A rogue access point is any wireless access point operating on or near a network without authorization from the organization running it. That's a broad category: it includes an employee plugging in a cheap consumer router to get better signal at their desk, just as much as it includes something an attacker deliberately planted.

An evil twin attack is a specific, deliberate kind of rogue access point: the attacker sets up an AP broadcasting the same SSID (and often mimicking the same authentication type) as a legitimate network the target already trusts, so that to a client device or a distracted user, it looks indistinguishable from the real thing.

How the Attack Unfolds

Why the deception works, and how it typically plays out, breaks down into a repeatable sequence:

1. Attacker broadcasts the spoofed SSID. Wi-Fi client devices generally decide which network to join based on SSID name and signal strength, not cryptographic proof of network identity. The evil twin broadcasts the familiar SSID, often at a stronger signal than the legitimate AP by simply being physically closer to the target.
2. Attacker optionally forces a disconnect. Evil twins are frequently paired with spoofed deauthentication frames, forgeable because 802.11 management frames historically lacked authentication, to knock a client off the legitimate AP.
3. Client auto-reconnects to the rogue AP. Devices that have connected to that SSID before will frequently reconnect automatically, because most operating systems are built to rejoin known networks without prompting the user. The client's automatic-reconnect logic lands on the rogue AP if it presents a stronger signal or lower channel congestion.
4. Client authenticates with no visible red flag. If the attacker also knows or guesses the legitimate network's password (common on networks using a widely-shared PSK, like guest Wi-Fi or a small office), the client authenticates directly against the rogue AP. There's typically no dialog box, no certificate warning, nothing that visibly distinguishes this reconnect from any other.
5. Attacker intercepts traffic. From that point, every packet the victim sends crosses through infrastructure the attacker controls, enabling traffic interception, credential capture on unencrypted services, and injection of malicious content into unencrypted sessions.

Where This Attack Is Most Practical

Public and semi-public Wi-Fi (coffee shops, airports, conference venues, hotel networks) is where evil twin attacks are most practical, precisely because those networks are open or use a shared, publicly known password, and users expect and accept an SSID they've seen before without scrutinizing it.

Enterprise networks running WPA2/WPA3-Enterprise with 802.1X are structurally more resistant to this specific attack, which is the direct motivation for the next section: when authentication depends on individual, mutually-verified credentials against a real authentication server rather than a shared passphrase anyone nearby can replicate, an attacker can clone the SSID but cannot trivially clone a valid answer to the authentication challenge.

802.1X and Enterprise Authentication

802.1X is an IEEE standard for port-based network access control, and it's the mechanism underneath WPA2-Enterprise and WPA3-Enterprise. Its job is to keep a network port, or in wireless terms, a client's association to the AP, effectively closed to real traffic until the connecting device or user has proven its identity against a central authentication server.

This is a fundamentally different trust model than a pre-shared key: instead of one shared secret every device on the network knows, each user or device authenticates with its own individual credentials, and no one presents the same secret as anyone else.

The Three 802.1X Roles

802.1X defines three roles. The supplicant is the client device requesting network access, running client software that initiates the authentication exchange.

The authenticator is the access point (or switch, on wired 802.1X) that sits between the supplicant and the rest of the network, blocking all traffic except authentication messages until the exchange succeeds, and then relaying those authentication messages back and forth without itself making the authentication decision.

The authentication server is the system that actually validates the supplicant's credentials, almost always a RADIUS server, which checks the presented credentials against a backend identity source such as Active Directory or an LDAP directory and returns an accept or reject decision to the authenticator.

EAP: The Credential Exchange Framework

The actual credential exchange between supplicant and authentication server runs over EAP (Extensible Authentication Protocol), which is a framework rather than one fixed method. It supports everything from certificate-based mutual authentication (EAP-TLS) to username/password methods tunneled inside a protected channel (PEAP, EAP-TTLS).

This flexibility is deliberate: it lets an organization choose an authentication method matched to its identity infrastructure and its security requirements, rather than being locked into one scheme, while still riding the same underlying 802.1X port-control mechanism.

RADIUS: Carrying the Conversation

RADIUS (Remote Authentication Dial-In User Service) is the protocol that carries the authentication conversation between the authenticator and the authentication server. In a WPA2/WPA3-Enterprise deployment, the AP forwards the supplicant's EAP exchange to a RADIUS server, which validates it against the directory and, on success, returns not just an accept message but also key material the AP uses to derive a unique session key for that specific client.

That per-client key derivation is the structural reason enterprise Wi-Fi doesn't share the evil twin exposure that a common PSK network does: there's no single shared secret an attacker can learn once and reuse to impersonate the network, because each session's keys trace back to an individual, centrally-verified identity rather than a passphrase distributed to everyone.

Wireless Detection and Monitoring

A Wireless Intrusion Detection System (WIDS), sometimes deployed as part of a broader Wireless Intrusion Prevention System (WIPS), monitors the RF environment around an organization's authorized network rather than relying only on wired-side logging. Because wireless attacks happen over the air, often against clients rather than against the wired network directly, a WIDS needs sensors, dedicated hardware or the organization's own APs operating in a scanning mode, that can observe 802.11 traffic across the channels in use and flag activity that doesn't belong.

Rogue and Evil Twin AP Detection

Rogue and evil twin AP detection is a core WIDS function: comparing observed SSIDs, BSSIDs (the AP's hardware MAC address), and signal characteristics against a baseline of known-authorized access points. An AP broadcasting a trusted SSID from a BSSID that isn't in the authorized inventory, or an unexpected AP appearing physically on-premises, is exactly the pattern an evil twin attack produces, and it's detectable precisely because the attacker has to broadcast something to lure clients in the first place.

Deauthentication Flood Detection

Because 802.11 management frames were historically unauthenticated, a burst of deauth or disassociation frames targeting one or many clients in a short window is anomalous enough to alert on, whether the intent is to force clients toward a rogue AP or simply to deny service to a target network. Organizations running WPA3 or WPA2 with Protected Management Frames enabled reduce the practical impact of forged deauth frames, but detecting the attempt is still valuable for identifying that an attacker is active nearby.

Unusual Probe Request Patterns

Client devices routinely send probe requests, broadcast queries asking whether a previously-connected SSID is nearby, as part of normal roaming behavior, and those probes can leak a device's history of networks it has joined. A WIDS can flag abnormal probing behavior, such as a device aggressively probing for an SSID that shouldn't exist in that physical location, as a potential sign of reconnaissance or an attacker actively trying to determine what trusted SSIDs are worth spoofing.

The aircrack-ng Suite, Used Defensively

The aircrack-ng suite is one of the most widely known tool families in wireless security work, and it's worth naming accurately in a defensive context. It's a set of utilities:

• airmon-ng: puts a wireless adapter into monitor mode.
• airodump-ng: captures 802.11 traffic and enumerates nearby networks and clients.
• aireplay-ng: generates specific 802.11 frames such as deauthentication requests.

Security teams use this same tool family defensively, to run authorized wireless assessments, validate that their own PMF and WIDS configurations actually catch the attacks described in this chapter, and understand what an attacker's tooling looks like from the network's point of view, rather than treating wireless attack techniques as an abstraction.