A student claims aircrack-class dictionary testing 'attacks the router CPU' to recover a municipal guest PSK. What correction is most accurate?
Select an answer to reveal the explanation.
Short Explanation
The heavy lifting happens on your laptop against a capture file—not by cooking the city's AP CPU. Once you have a solid handshake, guesses stay local. The access point is not your dictionary engine.
Full Explanation
A student claiming aircrack-class dictionary testing attacks the router CPU misunderstands offline Personal recovery: dictionary testing runs on the assessor's machine against captured handshake material, not by exhausting the AP's CPU with each guess. Municipal teaching should separate live online guessing from local offline cracking. That distinction drives noise, lockout, and RoE decisions.
'Aircrack always remote-executes guesses through the AP's web admin portal' fails because aircrack does not remote-execute guesses through the AP's web admin portal as its dictionary model. 'Router CPUs validate every dictionary line over the air before offline work begins' fails because router CPUs do not validate every dictionary line over the air before offline work begins. 'Only enterprise RADIUS servers perform offline dictionary work for PSK networks' fails because Enterprise RADIUS servers are not the only place offline dictionary work happens—PSK offline cracking is local to the assessor.
Exam caveat: online guessing against live gear is a different technique class with different risk—do not rename it offline. Operational check: in the city lab demo, show the cracker consuming local CPU/GPU against a .cap/hash with no per-guess AP hit, then contrast a forbidden live spray. Document the offline workflow in municipal training slides. In municipal wireless operations, record the rationale in the engagement notes so future assessors know which control or technique class was chosen and which failure modes the rejected options would create for city services.