Paasword for Config Tab

[ghpk]

Hi, I am little new to this great program but it has great potential where this could be used. I suggest you to have a password protected Config area, this would make it possible for a person to grant access to it for either Family members or even a customer.

Having free access to config option could give intentional or un-intentional alterations to settings which is risky for proper operation of deployed project.

Once this program grows on commercial use too, this option may lead to more frequent donations from commercial users, Fingers Crossed for WLED growth.

[Aircoookie]

Hi! This is similar to #308 and since it has been requested so much, I believe it would indeed be a good ideas to support various levels of password protection:

• None (currently supported)
• Only for firmware update (currently supported)
• Update + WiFi settings (currently supported)
• All settings
• Complete UI
• Complete UI + API (not sure on that one)

The reason I am hesistant with this so far is that the password is readable to anyone in the same network using simple attacks as we are not using HTTPS for resource reasons. So it would need to come with a big warning to not use the same password as for any important service. But some people would do anyways. On the other hand you are right that having this would bring great benefit to commercial users or those who have to share a network with non-trusted users at least against layman modification!

[SpaceCadetLights]

A great addition to this would be to sort the settings in a way where all the settings that changed fundamentally how the light was wired/setup would be in their own password protected area. This could include-

• led count
• led type
• color order
• On off button connection
• any other setting that is only setup once and configures the hardware of the light.

All other settings that, if set incorrectly wouldn't make the light unusable, could be open and freely available to use.

Just an idea :) Thanks again for the incredible work Aircoookie!!!

[w00000dy]

@Aircoookie We could "hide" the password using a crypto javascirpt libary like crypto-js. There we could do a browser-side hashing of the password. So the password can't be read easily by doing a simple network attack.

[darrellenns]

I think extending the password lock to allow locking the entire config section would be a big improvement. Packet sniffing/MITM attacks is certainly a concern, but even still some form of password protection is better than leaving it wide open. For more enterprise/commercial use, the lack of TLS can be mitigated to some extent by the end user network design (isolating management traffic from application/user traffic).

In the long term, a full permissions and API key system would be ideal. However, locking the config should be much simpler to implement and provide a good short term solution.

[pepsonEL]

Any news about implement pass for config ?

[nuvious]

I strongly recommend this as well. Out of the box these devices are setup very vulnerable. I could download this repo, modify the code to say provide a persistent reverse shell to give an attacker a back door into a network and OTA flash it, I could screw with the LED count/voltage to burn out a PSU (or maybe even set it on fire), or just be annoying and screw around with the lights. It's not enough that security can be enabled for certain things; it should be there from the beginning.

For node-to-node syncing operations I would recommend setting up public/private key pairs on install with every node having its public key available through an HTTP call (rest, simple http, whatever). One node would be designated the main node and other nodes being told which public key is the main node's key. Then when the main node changes it can digitally sign the command and child nodes can validate it. At the UI level all a user has to do is just check a box saying, "you're the main node" signaling the node should broadcast commands to be synced by child nodes and child nodes would populate a list of nodes on the networks by name/public key and the user would select which node was the "main node". So, no shuffling bearer tokens or anything like that around.

For user interface look at HOTP or TOTP options. During install maybe offer that HTOP or TOTP be setup and if they are then provide the user an HOTP or TOTP secret for their Google Authenticator/Microsoft Authenticator/Duo/whatever HOTP or TOTP app they prefer. The admin can then optionally add other admins or users where users could log in and change light settings but only admins can change things like LED pixel count/voltage, wifi settings, firmware updates, etc.

At the very least PLEASE at least setup a password from the start to protect against OTA updates. That's a huge potential vector for exploitation.

[Aircoookie]

Thank you for your input!

WLED is strictly intended for use in private, trusted networks.

Since it recently came to my attention though that CORS can be used by malicious site JS to change arbitrary settings, do a factory reset, or even flash malicious firmware (given no OTA lock is set), I will implement a simple HMAC based user authentication, which has the benefit that passwords can be salted and do not need to be transmitted in clear. This also makes it somewhat usable in semi-public networks such as a WiFi hotspot.

For syncing and other UDP interfaces supported by WLED I do not plan any authentication at the time being, as they can not be used to change settings, but only for setting the light state, furthermore the attack vector is smaller as browsers do not offer JS APIs for direct UDP communication.

[blazoncek]

PR #2565 will add PIN code protection to Settings pages.

[blazoncek]

Available in 0.14

[callimero]

WLED is strictly intended for use in private, trusted networks.

But still I don't want to change my sons lights accidentally. Even naming the instances would help :)

[blazoncek]

Even so... You can rename each instance of WLED in UI settings. For mDNS use WiFi settings.

[callimero]

Even so... You can rename each instance of WLED in UI settings. For mDNS use WiFi settings.

I am sorry, I just did not expect it in the UI Settings... That helps.