Hi! For technical reasons I shouls connect wled on a public wifi, I would preserve it from access anyone by web interface, unfortunely I can’t find an access password protect or change the easy target port 80. Any idea?
Probaly it’s possible to change the source script file, but I don’t have ideas how to compile and send back to esp8266.
Thanks for replies
Only thing off hand I could think of is put another router in your space. Tie wled to it.
You could then if needed create a reverse proxy or vpn to that router if needed.
ok thanks, I hope the author may introduce a login for the next version
Because WLED does not use encrypted communications, any login would be sent over the air (wifi) in plain text which anyone with a wifi radio can capture and then read with ease.
I understand what you mean though. Make it so an honest person stay honest.
I understand you too, but this it a second level of protection, I just want to keep out guys who love to destruct things just because they know it’s easy to do…
If you really are serious about improving the security of IoT devices, like WLED µcontrollers, consider using ESP32’s with ethernet instead of wifi. If you need wifi, install a secure wifi connection using a wifi gateway or bridge type device to get from the ESP32/ethernet → wifi widget → wifi AP (router).
You can do that now without any WLED code changes and it will be greatly more secure than any WLED coded solution, at least until ESP64’s (or whatever ESP32’s become that run 4x faster and have 4x memory.
Mate I hope you read my last post, my goal is not to protect it against attacks, but from easy access and corruption of the playing effect. I understand that to protect it I can put routers, access lists and so on… but for me it’s just enough avoid someone install app wled from phone, discover and change effect with one click. I hope you understand
Ahh, a fake login similar to the OTA password and so on, correct? I say fake in that the only thing that happens is WLED remembers someone logged in recently and has control for say 5 minutes without another login prompt.
Saving login state is not really necessary, correct?
Thank you for your kind support,
well… it should be something that hasn’t to disturb/interfer with the main user, something like it sets the password the first time, then the client ask for it and store into the app for future automatic connection without prompting. As well, the form on browser http://user:password@ipaddress may be an interesting easy way.
The important is for who don’t have stored password, to see only login form…
Let’s say you as the single valid user is using the WLED app to connect. That gives WLED an IP address that has successfully entered a password. Are you saying that from now on and forever that ip address should not get a password prompt?
Let’s say you now want to use a browser (either on your phone or on a different device without the ability to use the WLED app). Is the original connection going to get a login screen that then bumps the WLED app, or does WLED need to keep track of validated connections forever?
I think your intent is to only allow a single controlling user at a time if I understand correctly. If that is the case, perhaps a different screen should pop up when someone else attempts to login. “In use. Try back in 5 minutes.” Or something like that. After 5 minutes of no activity from a given user, then a login prompt would appear and then replace the previous authorized login.
Just a thought on how it might work best given the limited processing and memory resources.
Thanks for your kind interest.
I think it’s enough a password control every time a client will connect, and the comfortable format http://user: password@ip let the user and app (if it use the port 80 as I guess) open it quickly, or alternatively, if no password sent, show the login page where browser will suggest automatically the last password used. It’s up to browser send each connection the password. Yes it will rise the chances to be sniffed, but this is another story… and much more complicated to implement. Chances are, 99% of users connect wled to its local network and don’t nat on internet, we suppose a private network has not a sniffing problem.
Shortly, client sends http with password parameters, if not present or not correct it shows the login page
Hi!
I’m currently in the process of designing a system that improves the security of WLED by protecting the settings and optionally the main control UI with a password 
I’ve consulted with a security expert and it appears that I can implement it in a way that doesn’t require transmitting the password in clear over the network. The browser will store a hashed version of the password, so entering the password will be necessary only once per client.
Can’t promise if or when that will be available though.
2 Likes
Browser / wled app?
Only one can be “controlling browser” at a time?
I like your approach and forward-thinking!
Both
Will be stored so it only needs to be entered once per browser /app. You can authorize as many browsers as you want.
thanks, as I see wled is a multi platform server, it means I can have it “opened” in browser and on phone simultaniusly, and I can send commands from any of them, doesn’t matter in which order.
It would be fine to keep this logic (multiplatform), but I understand that introducing a control about who is operating… then the system can’t allow that forever. You should then intoduce a timeout, after that wled will about ask again for a login, on the app side this should be managed by app (which avoid to show the login page), on browser side… no other way that login page; but if the used saved it the browser should already contain it, so a click will solve all. I thin this is reasonable.
More or less it’s how a router WiFi behave, and almost all people had figured out that process.
That’s no problem to implement at all.
A timeout is not necessary, a once logged in device will be trusted unless revoked (sign out).
Google will also keep you signed in almost indefinitely, on as many devices as you have
For the user, nothing will change, except that they will have to enter the password once for every new device used to control WLED.
I am also planning 3 or 4 “protection levels”:
- Lvl. 0 Unprotected
- Lvl. 1 Authentication needed only for security critical settings (e.g. OTA update)
- Lvl. 2 Authentication needed only for changing settings (any)
- Lvl. 3 Authentication needed for accessing light control and the API in addition to settings
The current “OTA lock” more or less implements level 1. Lvl. 3 (introducing authentication to the JSON API) is not backward compatible, therefore I will likely set Lvl. 2 as default and allow Lvl. 3 as an option to protect the instance from unauthorized changes to light control as well
2 Likes
I’m interested in this implementation. I could use something like this on my other work. Just not sure how this works if all the communication is in the clear. Must be kind of like Diffie–Hellman key exchange.