A Wireless Audit Starts With the Verifier

I explored wireless auditing on an isolated network I controlled, using tools including Aircrack-ng, Hashcat, Reaver, Pixiewps and Kismet. They exposed several different meanings of “testing the Wi-Fi password.” A WPA2 authentication exchange, a WPS registration and a lookalike access point do not offer the same evidence or test the same secret. Understanding that difference is more useful than treating every tool as another route to a faster password guess.

My original account does not preserve captures, firmware versions, recovered credentials or measured guessing rates. This article develops the protocol reasoning behind that exploration. The worked examples explain the mechanisms, and the audit procedure is a proposal.

What makes a password guess checkable

Consider the conventional passphrase-based WPA2-Personal case. Both endpoints start with a shared secret. They need to establish session keys and demonstrate possession without transmitting the passphrase as plaintext. A useful capture can nevertheless provide enough evidence to check guesses locally, without asking the access point about every candidate.

The first step is deterministic. For this passphrase path, the pinned wpa_supplicant implementation derives a 32-byte key using PBKDF2-HMAC-SHA1, the SSID as salt and 4,096 iterations:

Illustrative derivation for the ordinary WPA2-Personal passphrase path:
PMK = PBKDF2-HMAC-SHA1(passphrase, SSID, 4096, 32 bytes)

The SSID matters even though it is not treated as a secret. Changing it changes this derivation's output. A precomputed result for one SSID cannot simply be reused as the result for another. A wrong SSID in an audit can therefore invalidate every candidate check while the tool appears to be doing substantial computation. This formula does not describe raw pre-shared keys or enterprise authentication.

The PMK, or pairwise master key, is only the beginning. Session key derivation incorporates the peers' MAC addresses and fresh nonces. A portion of the resulting pairwise transient key, the key confirmation key (KCK), authenticates Extensible Authentication Protocol over LAN (EAPOL) Key messages. The corresponding implementation orders the addresses and nonces, derives the key material and selects the message-integrity algorithm according to the negotiated authentication suite and descriptor version.

A checker can derive this material from a candidate passphrase and compare its calculated message integrity code with the captured one. The verification callsite zeroes the MIC field for that calculation. Addresses, nonces and message contents must belong to a consistent exchange. Four arbitrary packets labeled “handshake” are not sufficient evidence; conversely, a suitable subset can provide the inputs a particular checker needs.

This is a forward computation followed by comparison. It is not reversal of the password derivation or an exhaustive search of AES keys. Capture quality and candidate choice are as consequential as the speed of that computation.

Capture quality matters as much as speed: wrong SSID or mismatched messages invalidate every check. Diagram: Daniel Buttigieg

Search size is not a crack-time estimate

An illustrative model makes the limits precise. Suppose a secret contains exactly L independently and uniformly sampled characters from an alphabet of size A. There are N = A^L possible strings. Testing g distinct valid guesses gives success probability min(g/N, 1). In a complete fixed enumeration, the expected position of the secret is (N + 1)/2.

Under those assumptions, increasing a lowercase secret from ten to twelve characters multiplies the candidate space by 26² = 676. That is a comparison of possible strings, with the same alphabet and generation rule. It says nothing by itself about seconds, electricity cost or the distribution of human passwords.

Human choices have structure. A rule that appends a familiar suffix may cover much more probability than its fraction of the nominal character space suggests. A mask constrains the shape of candidates. Neither guarantees that the actual secret is included. Repeating exhausted candidates on faster hardware cannot recover a password outside that set.

The computation also has to be the right one. Hashcat's WPA documentation distinguishes PBKDF2-based processing and supported authentication-material formats. A generic SHA hash benchmark is not a measurement of WPA2 passphrase guesses per second. Even a relevant benchmark would need its mode, hardware, implementation and workload before it could support an estimate for a particular audit.

The strongest defensible negative result is correspondingly narrow: these valid candidates did not match this validated verifier. “The password is secure” does not follow.

Before trusting that result, I would use a deliberately generated known-password fixture using the same authentication path and import process. The known candidate should match; a wrong candidate should not. This checks the measurement chain before interpreting the unknown case. The record should include the exact SSID encoding, negotiated authentication and cipher, coherent source frames, import diagnostics and the number of distinct valid candidates actually evaluated. These are proposed controls, not tests performed for this article.

Collection has its own uncertainty. Kismet's capture documentation explains the limits imposed by wireless reception. Range, channel selection, interference and capture support affect what can be observed. A receiver hopping between channels has observation gaps. Missing a handshake during those gaps does not show that no handshake occurred, and a tool's name alone does not establish the behavior of every capture mode.

A second secret can defeat the first one's strength

WPS adds an enrollment path. Its PIN is a different secret from the WPA passphrase. If that path discloses network credentials after weaker authentication, increasing passphrase complexity does not repair the enrollment mechanism.

The historical CERT/CC WPS vulnerability note describes feedback that allows the two PIN portions to be tested separately. The arithmetic needs care. An eight-digit decimal string has 10^8 possibilities, but a final checksum digit reduces the valid PIN space to 10^7. With the vulnerable split feedback, the upper search budget becomes 10^4 + 10^3, or 11,000 half-candidate checks.

That number assumes the static-PIN path exposes the required feedback and permits continued attempts. It is not 11,000 guesses against the WPA passphrase, a universal recovery time or evidence about a current router. Online throughput, lockouts and rate limits determine how many attempts can actually be made. The note dates from 2011; my account does not establish whether my router was affected.

Pixie Dust concerns another mechanism. In Dominique Bongard's 2014 disclosure, WPS commitments combine PIN-half-derived values with secret nonces and session material. Predictable or absent secret nonces in particular implementations can make candidate PIN checking feasible offline. The failure concerns entropy in those implementations, rather than a general theorem that every WPS device has the same weakness.

Acquiring the necessary material is part of the threat model. The Pixiewps project lists inputs including commitment hashes, public keys and AuthKey. An arbitrary passive capture does not automatically supply all of them. An active registration exchange and the offline computation performed afterward are different stages with different access requirements.

This explains why two superficially similar WPS attacks call for different reasoning. Throttling repeated online PIN attempts addresses an online oracle. It does not by itself repair weak randomness after sufficient material for offline checking has been obtained. Strong nonce generation, in turn, does not eliminate every risk of an exposed static-PIN enrollment path. Inspect the actual enabled mechanism before assigning either finding.

WPA3 changes the evidence available to an observer

WPA3-Personal uses SAE, Simultaneous Authentication of Equals. Its password-authenticated key exchange changes what a passive transcript exposes. The aim is to establish a shared authenticated key without leaving the ordinary reusable offline password checker found in the PSK case.

A conceptual elliptic-curve sketch from RFC 7664's Dragonfly exchange shows the missing dependency. Both peers map the password to a point P. Alice chooses fresh private value a and mask m; Bob independently chooses b and n. Their commitments combine those secrets:

Conceptual algebra, not implementation code; q is the group order.
Alice sends: sA = (a + m) mod q, EA = -mP
Bob sends:   sB = (b + n) mod q, EB = -nP
Alice computes: a(sB P + EB) = abP
Bob computes:   b(sA P + EA) = abP

Multiplication here means elliptic-curve scalar multiplication. Each participant uses a private value to derive the same point, from which confirmation keys follow. Even a correct password guess lets a passive observer reconstruct aP and bP, rather than the shared abP. Obtaining that point from those public values requires solving the assumed-hard Diffie-Hellman problem. The guessed password alone therefore does not reconstruct the confirmation key as it reconstructs a WPA2 PSK-derived key.

Fresh private randomness, valid group inputs and absence of additional leakage matter. An active peer can still test a guess through interaction. The RFC is Informational IRTF background, rather than the complete current IEEE SAE specification or assurance about every implementation.

That distinction matters when reading security research. Vanhoef and Ronen's Dragonblood paper, published at IEEE S&P in 2020 following disclosure in 2019, combined implementation tests, code analysis and side-channel experiments. Password-dependent conversion to a group element could reveal information that filtered candidate passwords offline. The extra leakage supplied evidence that an ordinary passive transcript was not supposed to provide.

The access requirements differed. Wireless timing observations required protocol interaction within range. The cache experiment additionally used an unprivileged spy process on the same physical hardware. Its hostap test targeted commit 0eb34f8f2 with P-256 on a specified Intel/Ubuntu platform. Treating that experiment as an ordinary remote sniffer would remove a central assumption. The paper also distinguishes SAE from EAP-pwd and studies selected historical implementations, not every current WPA3 deployment.

Later implementation support also matters. Android's current documentation identifies Hash-to-Element (H2E) and Transition Disable support in Android 12. H2E concerns password-element conversion; Transition Disable tells a client to stop using the WPA2 path. A historical password-element leakage result is a reason to inspect the deployed implementation and mitigations. It is not evidence that every current device remains vulnerable or that a feature supported by a platform was negotiated in one session.

Compatibility introduces a separate issue. If the same password still authenticates a reachable WPA2-Personal path, that path retains its own offline-verification exposure. Advertising WPA3 capability does not erase it. Record the authentication and key-management suite actually negotiated, alongside the alternatives permitted by the saved client profile. A later four-way handshake does not make an SAE-derived master key equivalent to the ordinary passphrase-derived PSK formula.

A network name is not an authenticated identity

A lookalike access point shifts the problem again. Copying an SSID creates a familiar label. It does not establish possession of the expected key or prove that a client completed authenticated association. A party that already knows a shared password can demonstrate possession, which is still different from proving a unique operator's identity.

Any device can broadcast a familiar network name; identity has to come from the authentication. Photo: Mk2010 / Wikimedia Commons, CC BY-SA 4.0

A captive portal adds an application interaction. A page asking someone to enter a Wi-Fi password is not the wireless key exchange. If the user gives the secret to the wrong service, no password derivation needs to be broken. Conversely, creating a portal does not automatically obtain credentials, bypass HTTPS or execute code in a browser.

The web identity check remains specific. RFC 9525 describes verification against the expected service identity. A valid certificate for a lookalike operator's own domain does not authenticate the domain the user intended to visit. Network association, TLS identity and human interpretation are separate boundaries.

Protected Management Frames address another boundary. HPE Aruba's documentation identifies protection for robust management frames, including forged deauthentication and disassociation after association. Its configuration table distinguishes PMF capability from requiring it: an optional mode can admit clients without that protection, whereas required mode excludes unsupported clients. This is protection for particular signaling, not immunity to radio interference or every interruption of service.

What an audit should leave behind

A useful audit record connects a conclusion to a specific path. It identifies the authorized access point and client, their relevant versions, the negotiated mode, the evidence acquired, the verifier used and the controls that showed the checking process worked. It records candidate coverage separately from elapsed time. A positive match needs confirmation on the authorized path; a negative result retains its bounded meaning.

That record also makes deployment trade-offs visible. SAE-only operation may remove a legacy PSK path where client compatibility permits. Unneeded WPS PIN enrollment can be removed independently. PMF settings concern supported management protection. Firmware maintenance concerns implementation defects. None of those choices substitutes for the others, and none is a deployment I can infer from my original tool list.

One practical consequence follows from tracing the secret across paths. Moving legacy clients onto another network does not contain password exposure if both networks reuse the same secret. A verifier obtained on the weaker path still tests the credential used on the stronger one. Separation becomes meaningful when the authentication material and permitted access are separated too. That is the architectural question to settle before spending more time making guesses faster.

---

Image credits

• Cover: ELECOM WRC-300FEBK WPS WiFi router by Syced, CC0, via Wikimedia Commons
• Wireless router, internal components (LevelOne WBR-6002) by Mk2010, CC BY-SA 4.0, via Wikimedia Commons
• Diagrams by Daniel Buttigieg.