WIFI Access Point: Detect incorrect password entered by station (IDFGH-13377)

[koneill-txwireless]

Is your feature request related to a problem?

Client has stringent cyber-security requirements and needs to be able to react, taking the matter into their own hands, to an incorrect password being entered more than once.

Describe the solution you'd like.

When a station attempts to connect to the ESP32 WIFI access point, with an incorrect password, a callback with a reason of "incorrect password" or something similiar.

Describe alternatives you've considered.

We looked at using WIFI_EVENT_AP_STADISCONNECTED but as was correctly pointed out, that is only applicable when a station was connected in the first place.

We tried to monitor the ESP32's reaction to an incorrect password being entered, it does log it (deauth/disassoc, reason: 3), but we can't find a way to react to it.

Additional context.

The client is on v5.1.4 of IDF.

[DarmorGamz]

You've registered the WIFI_EVENT_AP_STADISCONNECTED event and logged the below in the callback?

wifi_event_ap_stadisconnected_t* sta_disconnected = (wifi_event_ap_stadisconnected_t*)event_data;
ESP_LOGI(DEBUG_TAG, "STA disconnect reason (%d). ", sta_disconnected->reason);

I'd expected a WIFI_REASON_4WAY_HANDSHAKE_TIMEOUT value or similar, but this is how you capture the incorrect password.

[koneill-txwireless]

You've registered the WIFI_EVENT_AP_STADISCONNECTED event and logged the below in the callback?

wifi_event_ap_stadisconnected_t* sta_disconnected = (wifi_event_ap_stadisconnected_t*)event_data;
ESP_LOGI(DEBUG_TAG, "STA disconnect reason (%d). ", sta_disconnected->reason);

I'd expected a WIFI_REASON_4WAY_HANDSHAKE_TIMEOUT value or similar, but this is how you capture the incorrect password.

I believe you need to be connected in the first place to get the WIFI_EVENT_AP_STADISCONNECTED event. Thank you though.

[KaeLL]

@koneill-txwireless no, you don't. A connection attempt with a wrong password indeed generates a WIFI_EVENT_AP_STADISCONNECTED event, which is also stated here.

[koneill-txwireless]

@koneill-txwireless no, you don't. A connection attempt with a wrong password indeed generates a WIFI_EVENT_AP_STADISCONNECTED event, which is also stated here.

Thank you but have you actually confirmed this? Have you the log showing an incorrect password being entered? I have tested this yesterday and no event is generated when an incorrect password is entered.

Espressif have also confirmed that WIFI_EVENT_AP_STADISCONNECTED cannot be used as "we can not use WIFI_EVENT_AP_STADISCONNECTED to detect failed connection attempts because WIFI_EVENT_AP_STADISCONNECTED is only posted when a successfully connected device disconnects from softAP."

[sarveshb14]

Hi @KaeLL , https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-guides/wifi.html#wi-fi-reason-code-related-to-wrong-password is application for station only.

For softAP, WIFI_EVENT_AP_STADISCONNECTED event is only posted when a previously successfully connected device disconnects from softAP.

[KaeLL]

I stand corrected. The event being reported to the app layer is the one notifying about a channel change since the last connection attempt, namely WIFI_EVENT_HOME_CHANNEL_CHANGE, which I overlooked because right above the esp_event log, there's the following log from the esp-wifi-lib I (32711) wifi:station: 32:0e:53:a2:78:fa leave, AID = 1, reason = 15, bss_flags is 34311266, bss:0x3ffb9d04 which means the event is being produced, but is not getting reported to the loop?

[koneill-txwireless]

Hi @sarveshb14, is this feature something you guys are considering?

Our client is chasing us again for when we will have a solution for this. They have come from a Linux based platform to the ESP32 and it was a key feature on their legacy solution.

[sarveshb14]

Hi @koneill-txwireless , apologies for the delay. May I know which chips are you planning to use ? I will provide you with a patch.

[koneill-txwireless]

That's great news. The ESP32S3 is the only chip our client uses.

[sarveshb14]

Hi @koneill-txwireless , This is indeed an interesting case.

Please try with following esp-idf patch and also replace wifi libraries for S3 in components/esp_wifi/lib/esp32s3.

With the above change, we have added WIFI_EVENT_AP_WRONG_PASSWORD event which gets triggered when external stations try connections with wrong password. This event is supported for WPA2, WPA3(SAE) and WPS WiFi-securities. Changes are in wpa_supplicant only. Which primarily takes care of connection establishment.

Do let me know if this handles your use case and any additional suggestions/requirements if any.

[kriegste]

I reckon this is a helpful addition to the regular IDF on all chips.

[koneill-txwireless]

Hi @sarveshb14, apologies for being slow to get back to you, I was off the last few days.

Your patch is working and working well. The only thing I noticed was that it appears to be triggered four times per attempt. Is there a way that I can reduce this to one per event? Should I be clearing event bits?

[sarveshb14]

Hi @koneill-txwireless , for WPA2, we (softAP) know that station is trying to connect with wrong password if mic-verification (kind of signature verification) fails during the processing of M2 message (of 4-Way-Handshake). Its normal for stations to re-transmit frames in case of failed connection in the assumption that the frame was previously lost in the transmission.

Hence you are seeing the event getting triggered for 4 times. It is actually the station which is re-transmitting the frame for 4 times (due to wrong password). This can also happen for WPA3.

I do not think we can do much here. We have to report the event every time a wrong frame (due to wrong password) is received.

[koneill-txwireless]

That's fine, thank you for the background on it. We can manage the multiple triggers.

[KaeLL]

@sarveshb14 What's the ETA for that on master?

[koneill-txwireless]

Hi @sarveshb14, is there a possibility that this will be merged into the next release of v5.1, e.g. v5.1.5? It is the release line that our client is on and they are sensitive to big jumps.

[koneill-txwireless]

Hey @sarveshb14, any update on this?

Client is keen to get this integrated and tested.