Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
koneill-txwireless opened this issue Aug 1, 2024 · 19 comments
Assignees
Labels
Status: Opened Issue is new Type: Feature Request Feature request for IDF

Comments

@koneill-txwireless
Copy link

koneill-txwireless commented Aug 1, 2024

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.

image

Additional context.

The client is on v5.1.4 of IDF.

@koneill-txwireless koneill-txwireless added the Type: Feature Request Feature request for IDF label Aug 1, 2024
@github-actions github-actions bot changed the title WIFI Access Point: Detect incorrect password entered by station WIFI Access Point: Detect incorrect password entered by station (IDFGH-13377) Aug 1, 2024
@espressif-bot espressif-bot added the Status: Opened Issue is new label Aug 1, 2024
@DarmorGamz
Copy link

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
Copy link
Author

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
Copy link
Contributor

KaeLL commented Aug 8, 2024

@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
Copy link
Author

@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
Copy link
Collaborator

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
Copy link
Contributor

KaeLL commented Aug 8, 2024

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
Copy link
Author

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
Copy link
Collaborator

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
Copy link
Author

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

@sarveshb14
Copy link
Collaborator

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
Copy link

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

@koneill-txwireless
Copy link
Author

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?

image

@sarveshb14
Copy link
Collaborator

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
Copy link
Author

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

@KaeLL
Copy link
Contributor

KaeLL commented Aug 21, 2024

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

@koneill-txwireless
Copy link
Author

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
Copy link
Author

Hey @sarveshb14, any update on this?

Client is keen to get this integrated and tested.

@koneill-txwireless
Copy link
Author

Since this was requested, v5.1.5 has been released. The libraries provided are targetted at v5.1.4 I think as you get linker errors on v5.1.5. Would it be possible to get new WIFI libs with incorrect password detection functionality for v5.1.5?

@sarveshb14
Copy link
Collaborator

Hi @koneill-txwireless , Sorry for the late response.

The functionality to detect the station using wrong pasword/pin is implemented completely in wpa_supplicant component of esp-idf. You can omit the library change and cherry-pick the commit directly on v5.1.5. You will still be able to compile your application without any linking errors. (library change is just to make sure that the version of public header file components/esp_wifi/include/esp_wifi_types.h is not different in esp-idf and libraries)

We will get this feature merged in esp-idf soon. Till then please use this patch as it is on esp-idf (without the libraries).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Opened Issue is new Type: Feature Request Feature request for IDF
Projects
None yet
Development

No branches or pull requests

7 participants