What this simulates: An attacker within RF range of a WPA2-PSK network. The attacker forces a connected client to reconnect (deauth), captures the 4-way handshake during the reconnect, then runs an offline dictionary attack against the PSK. Nothing here uses real WiFi — it's all in-browser simulation showing the timeline and the crack mechanics.
Try the three preset PSKs to feel how dramatic the difference is. The same handshake, the same wordlist, the same attacker hardware — the only variable is the password.
Phase 1 · Pick a target PSK and capture the handshake
Choose a PSK to deploy on the AP. Then either wait for the natural client reconnect (slow), or send a deauth burst to force one immediately (fast — what an attacker actually does). PMF defeats the deauth setup; toggle it to see the difference.
Phase 2 · Offline dictionary attack
Once the handshake is captured, the attacker walks away. The attack continues offline against the AP's PSK using a wordlist. We're simulating a 10,000-entry rockyou-style wordlist at a modest 200k attempts/sec (a single mid-range GPU). Real hashcat on a high-end rig does ~1-2M/sec for WPA2 — even faster.
Result
What just happened · the briefing
Walk through what the simulator did, attack-step by attack-step:
1. Deauth burst: The attacker sent forged 802.11 deauthentication frames pretending to be the AP. Without PMF, the client can't verify these frames, so it disconnects. With PMF enabled, those forged frames are silently dropped and the client stays connected — that's why deauth is grayed out when you check the PMF box.
2. Reconnect & handshake: The client immediately tries to reconnect. The 4-way handshake (4 EAPOL-Key messages) crosses the air. The attacker, listening in monitor mode, captures all four. The PSK never crossed the air — only the nonces and a MIC derived from the PSK.
3. Offline crack: With the handshake in hand, the attacker walks away. From any laptop, anywhere, they can now run a dictionary attack: for each candidate password, compute PBKDF2-SHA1(password, SSID, 4096) to get the PMK, then derive the PTK using the captured nonces, then check whether the resulting MIC matches the captured MIC. When it matches, the password is found.
4. The math: A common 8-character lowercase-only PSK has ~2×1011 possibilities. At 1M/sec on a GPU, that's ~2.6 days max. A top-1000 wordlist run takes milliseconds. A 16-character random PSK has ~3.4×1030 possibilities — longer than the heat-death of the universe at current cracking speeds.
Try this · experiment with the variables
Run the simulation with each variation and notice what changes:
- PMF enabled vs disabled. With PMF on, the deauth burst is blocked. The attacker has to passively wait for a natural reconnect — could be minutes, hours, or never. Operationally PMF is the single highest-value setting on this whole page.
- Strong vs weak PSK. Same handshake, same attacker, same wordlist. The only variable that matters is the PSK.
Password123falls in milliseconds.K7#mPx2$qLn4!Vw9zfalls in (effectively) never. - What WPA3-SAE would change. SAE makes every guess an online interaction with the AP, rate-limited and slow. You can't run a 10,000-attempt dictionary in 0.05 seconds against SAE. The whole offline-crack class of attacks evaporates.
The defensive lessons from this lab are three settings: turn on PMF, require a long random PSK (or move to WPA3-SAE), and do not assume your network is protected because no one is connecting — the attacker forces the reconnect.
The thing that surprises every student here: the PSK never touched the air. The attacker derives everything from publicly visible frames and the math of PBKDF2. "It's encrypted" isn't enough — the encryption is only as strong as the input to the key derivation.