Hello.
It's not an Issues, it's a security request for future versions. It would be nice if the management could be accessed via https, username and password.
It's a suggestion.
Thank you very much,
Hello.
It's not an Issues, it's a security request for future versions. It would be nice if the management could be accessed via https, username and password.It's a suggestion.
Thank you very much,
I confirm, it鈥檚 a must have feature.
can i ask why ?, do you guy's expose port 80 on your IoT VLAN to the web ?, if so you would also require a security certificate ?
can i ask why ?, do you guy's exposed port 80 on your IoT VLAN to the web ?
Because a WiFi network can鈥檛 be secured at 100%. So if an attacker goes through, then it鈥檚 better to have a second security. So securing Shelly Homekit with https and user/pass would be great.
If not, once the Wifi is hacked, then opening the garage doors is not an issue 馃榿
ok, noted.
then also, maybe an option to allow the user to chose the port that webpage is hosted would also help ?, port 80 is very common....
HTTPS with a proper certificate is impossible. self-signed is theoretically possible but wouldn't make much sense. authentication - agree, we should have it.
I think with a username - password and serious port choice the most recommended. yes.
that what i was thinking HTTPS there would not be enough space on device, but HTTP with login should be enough.
que lo que estaba pensando HTTPS no habr铆a suficiente espacio en el dispositivo, pero HTTP con inicio de sesi贸n deber铆a ser suficiente.
Othe firmware type, tasmota, espurna use http. I don't think it's a big problem. Even the user is default which is one less security option.
HTTP Access would be fine (username + password) like shelly original firmware.
Only somewhat related to this ticket, but:
Currently WPA2 encryption for Wifi is supported.
Is it possible/useful to also support WPA3 as well?
+1
This is pretty important for me as well - access to one's WiFi would enable someone to control secure devices that are implemented with Shelly1. Whereas other HomeKit devices can't be controlled via WiFi alone. Locking down access to these devices with a secure HTTPS login would be of great use.
we would need an API token aswell if this is done.
If we use HTTP Basic Auth for the UI we can use it for the API as well, http://<user>:<password>@<host>/rpc/... should work.
If we use HTTP Basic Auth for the UI we can use it for the API as well,
http://<user>:<password>@<host>/rpc/...should work.
no way!!!, i will use clear text password in an API request. your asking for trouble and be hacked.
What's the difference between an clean text password and an api key? Both is readable if we don't have https and the user:password will be encoded as an token and send via header.
What's the difference between an clean text password and an api key? Both is readable if we don't have https and the user:password will be encoded as an token and send via header.
i do not trust giving the clear text password to another manufacure device (ie stock shelly fw aka Button1 to control a homekit shelly). that device "could" have access to other cloud servcies and other remote services.
with an API Token it can not get acces to the webUI of the shelly homekit device,
the API token can be any random key, that can be changed at any time by the user, you could even go like apples app password feature, and allow multple tockens per device, could have one for each device that requires tocken access.
but one should be sufficient.
i'll leave this open as it is a good request.
Most helpful comment
that what i was thinking HTTPS there would not be enough space on device, but HTTP with login should be enough.