-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Wireless Password Leak #374
Comments
you can disable the multipress functions.
the password is also visible on the web console and via mqtt.
The mindset is that if you have people in your house hitting the buttons or
otherwise sending the devices commands to switch to AP mode, you have problems
far more severe than the leakage of the password.
|
The problem is that nobody pressed the buttons or sent any command to switch the AP mode. Because you have passwords in other places does not make the issue less serious, maybe they should also be fixed. |
It's very useful for troubleshooting, a config option to mask them is an option
(but takes code and memory that are both in short supply)
If you have a device switching to AP mode without you telling it to, then you
either have it configured to do so when it looses it's wifi connection, or
someone is telling it to do so without you knowing about it. you should
investigate your logs (and your config) to know which is happening.
|
Not to hijack the thread, but David is it possible to not have the sonoff go into AP unless a physical hardware button is pressed? (and nothing else?) Perhas Adam can start with that route and observe the behavior. |
yes, change the WIFI_CONFIG_TOOL settings to something other than WIFI_MANAGER
|
To be honest I think having a option is overkill, just don't write the current password in the web interface, no extra memory is required, leave the text field to input eventual new password changes, but not use the same textbox for current passwords. If the person want to change the password it will still be possible, there is no reason to have the current password in the webinterface. In the current design the user can't even verify in a convenient way that he put the correct password, since the password is masked by the browser.
Yes, but this is not at the same level, I can protect the mqtt/web interface with username and password. In that situation it would not be possible to discover the wireless password. |
This does seem to be an issue. If I set the mode to After that though, it always starts wifi manager instead of wifi restart every time it loses wifi (instead of simply restarting). I only want it to start wifi manager when I press the button. Never automatically. Is there a workaround? Why does it store what config tool was last used and use that every time in the future? EDIT:
Hopefully this helps anyone concerned with this issue. |
I noticed the same thing. When e.g. my Router updates its ap is down, then the Sonoff opens its own WiFi-AP, which is a very nice feature. But everyone could now read my wifi password. |
@ascillato Ok, thanks but I guess you referenced the wrong Issue: #1587 |
Yes. You are right! That one I wanted to reference. Thanks! 👍 |
I have been using my sonoff basic version without any issues for the last weeks. I noticed something strange some days ago. I could not see the sonoff connected to my network, it seems that it went to the AP mode without any intervention from myself (bug?). This is a problem since it was in AP mode and anyone could:
I don't think the current passwords should be available when the source code of the page is seen. As a defense in depth I would suggest that this should be applied in other pages of the device that have the same password textboxes.
The text was updated successfully, but these errors were encountered: