How to programatically validate WPA passphrase on Linux?

Question

I'm trying to validate the user's input of SSID and WPA Passphrase for a WPA connection. My program is a Python program running on an embedded Linux platform. I can validate an Access Point with SSID exists by parsing the output of a iwlist scan subprocess. Validating the Passphrase, however, is less straight forward. So far, the only solution I've come up with is to parse the output of

wpa_supplicant -Dwext -iwlan0 -c/tmp/wpa_supplicant.conf

looking for

"pre-shared key may be incorrect"

or the kernel message

"OnDeAuth Reason code(15)"

(which means WLAN_REASON_4WAY_HANDSHAKE_TIMEOUT according to the wpa_supplicant source).

Interpreting a handshake timeout as an invalid Passphrase seems plain wrong. Besides that, that approach requires waiting for some output from a subprocess and assumes the absence of error messages means the Passphrase is valid.

Googling around this just returns me a lot of questions and advice on how to hack a WPA connection! There's no wpa_cli or iwevent in the yum repository for my target platform and I'm unsure how to go about getting a third-party python package running on my target.

Question: What's the simplest way of validating the Wifi WPA Passphrase?

Answer 1

Well, a not-so-straightforward (yet the only possible) way to go about fulfilling your needs would be initiating a four-way handshake with the AP.
Since you're coding in Python, Scapy would be your best option for crafting EAPOL message packets.
You'll have to know the structure of the EAPOL packets though, and fully implement it in your code.
You'll also have to recode, in Python, the functions for key generation, most (if not all) of which are PRFs **(Pseudo Random Functions); alternatively, you could import ready-compiled .DLL's to do the encoding for you.

However, it would be enough to manage only the first 3 messages from the four-way handshake:
If, after several connection attempts, the AP doesn't send the 3rd key message, then the MIC (Message Integrity Check) from the STA didn't match the one generated by the AP, and the password is thus invalid.
Otherwise, it is.

Note: wpa_supplicant follows the same procedure for authentication and connection, however it continues on for obtaining extra information like IP address and what not... That's why I said it's the only possible way.