WPA2 vs WPA3 — Side-by-Side Comparison
| Property | WPA2 PSK | WPA3 (Personal) |
|---|---|---|
| Encryption algorithm | CCMP (AES-based) | GCMP (AES + GMAC) |
| Integrity check (MIC) | CCMP MIC | GMAC (part of GCMP) |
| Handshake mechanism | Four-way handshake | SAE (Simultaneous Authentication of Equals) |
| Hash transmitted over air? | Yes — attacker can capture and crack offline | No — session key derived independently via Diffie-Hellman; never transmitted |
| Offline brute-force attack possible? | Yes — GPU/cloud cracking with no lockout | No — nothing to capture; no hash available for offline attack |
| Mutual authentication? | No — only client authenticates to AP | Yes — both sides prove knowledge of passphrase |
| Forward secrecy? | No — PSK compromise exposes all past sessions | Yes — unique session key per connection; past sessions safe |
| Management frame protection | Optional (802.11w) | Mandatory (802.11w required) |
| Key size | 256-bit (derived from passphrase) | 256-bit (derived via SAE/Diffie-Hellman) |
Three Wireless Security Modes — When to Use Each
| Mode | Authentication | Key Management | Use Case | Key Risk / Limitation |
|---|---|---|---|---|
| Open System | None — any device connects | No encryption | Public hotspots where access is intentionally unrestricted | Zero confidentiality; all traffic visible; must rely on application-layer encryption (HTTPS, VPN) |
| WPA3-Personal (PSK) | Shared passphrase (all users share one key); SAE protects the handshake | Single pre-shared key; unique session keys per SAE exchange | Home networks; small offices; environments without RADIUS infrastructure | Shared secret — if passphrase is compromised, all users are exposed; no per-user audit trail or individual access revocation |
| WPA3-Enterprise (802.1X) | Individual credentials via RADIUS — username/password, certificates, or MFA token | Unique key per user session; derived from RADIUS-based auth exchange | Corporate networks requiring individual accountability, per-user access control, audit logs, and VLAN assignment | Requires RADIUS infrastructure; more complex to deploy; certificate management overhead for EAP-TLS |
AAA Framework — Four Sequential Steps
| Step | Question Answered | Mechanism | Example in Wireless Context |
|---|---|---|---|
| Identification | Who are you? (claim) | User presents a username or identity | Employee types their corporate username to connect to the WPA3-Enterprise network |
| Authentication | Prove it | Password, certificate, biometric, MFA token — validated by RADIUS against directory | RADIUS verifies the password (or certificate) against Active Directory; returns Access-Accept or Access-Reject |
| Authorization | What are you allowed to access? | RADIUS returns authorization attributes: VLAN, bandwidth limits, session time, permitted resources | After authentication, RADIUS assigns the user to VLAN 20 (engineering) rather than VLAN 30 (guest) |
| Accounting | What did you do? (record) | RADIUS logs session start time, end time, duration, data volume, assigned resources | RADIUS accounting records show the user connected at 08:45, disconnected at 17:20, transferred 2.1 GB — useful for audit, billing, and anomaly detection |
802.1X — Three Component Roles
| Role | Typical Device | Function | What It Does NOT Do |
|---|---|---|---|
| Supplicant | Client laptop, smartphone, or workstation | Initiates authentication by presenting credentials; responds to authenticator challenges; completes EAP exchange | Does not validate its own credentials; does not make access decisions |
| Authenticator | Wireless access point (for Wi-Fi) or network switch (for wired 802.1X) | Enforces port-level access control — blocks all traffic until authentication succeeds; passes EAP messages between supplicant and authentication server; opens the port on Access-Accept | Does NOT validate credentials itself; acts as a relay/policy enforcement point, not a credential validator |
| Authentication Server | RADIUS server (FreeRADIUS, Microsoft NPS, Cisco ISE) | Receives forwarded authentication requests from the authenticator; validates credentials against directory (AD, LDAP); returns Access-Accept (with optional authorization attributes) or Access-Reject; performs accounting logging | Does not enforce access directly — sends the decision back to the authenticator, which acts on it |
WPA2 PSK Attack Flow vs. SAE Defense
| Stage | WPA2 PSK (Vulnerable) | WPA3 SAE (Protected) |
|---|---|---|
| Client associates with AP | Four-way handshake occurs — hash of PSK + nonce transmitted in frame 2 | SAE commit phase: both sides derive a shared value using Diffie-Hellman; no PSK hash transmitted |
| Attacker captures exchange | Attacker captures the four-way handshake passively; leaves network; begins offline cracking | Nothing useful to capture — no hash, no crackable value is transmitted |
| Offline cracking attempt | Attacker runs dictionary + brute-force attack on captured hash; no lockout; GPU acceleration possible; cloud cracking services available | No offline attack possible — the session key was derived independently, never transmitted; attacker has no starting material |
| Passphrase later compromised | Attacker decrypts all previously recorded sessions — no forward secrecy | Previously recorded sessions remain protected — each session used a unique derived key; forward secrecy maintained |
EAP Methods Comparison
| EAP Method | Client Certificate Required? | Server Certificate Required? | Security Level | Common Use Case |
|---|---|---|---|---|
| EAP-TLS | Yes — mutual TLS | Yes | Highest — both sides authenticated with certificates; no password involved | High-security enterprise environments with PKI infrastructure; eliminates password-based auth entirely |
| PEAP (Protected EAP) | No | Yes — server cert creates TLS tunnel | High — inner auth (usually MSCHAPv2) is protected inside TLS tunnel | Most common enterprise deployment; uses password-based inner auth protected by server-cert TLS tunnel |
| EAP-TTLS | No | Yes — server cert creates TLS tunnel | High — more flexible inner auth methods than PEAP | Similar to PEAP but supports legacy or non-Microsoft inner auth methods |