Hi, I just noticed the Update Tool can be accessed without authentication when Hub IU Security is enabled, would it be possible to add it?
Or would that require accessing data that may not be available when having issues with the hub which is when this would be necessary? maybe at least asking for a pin or something to be able to submit...
Running 2.0.1 ... fwiw I can't reproduce this, I get the login page when directly hitting http://(ip address)/hub/firmware
(iOS Safari)
No that's not the Update Tool I was talking about, try http://(ipaddress):8081
Gotcha - confirmed for me also, can access without auth.
Me too running 2.0.1.
Port 8081 aka UpdateTool has no plans to be password protected. The only thing that can be done here is rolling back to a previous version. This does not change your database, so you would still have authentication after a roll back, unless you rolled back to a version that didn't have authentication available.
mmm, that is not very good security wise... is there any way to disable it? I guess that is risky, I know many people here don't care about security (most it seems by the look of things) but I guess due to my line of work I tend to side towards it...
What is the security risk? Your database still has its user and password.
You can only roll back to the last version, which has security in it anyway.
Well you just said it above, you could roll back to a version with no security, couldn't you? not sure as I have never used this...
That's said, it seems to me user authentication was not added for this reason either, otherwise it would at least have SSL, but mainly to avoid anyone to so easily mess around with something they should not and break what works...
If you have updated to 2.0.1 the only version available to roll back to would be 2.0.0
SSL is something we have on the list to do as well.
Nice
That is great to hear!
I am not saying I need this now, there are much bigger fish to fry, I'm just saying that given you guys seem to have started investing considerable time and effort on making the platform secure then you should consider adding security to this page too... it would be a shame to spend all that energy locking the door and leave the window open...
There is no window open. This page needs to be insecure to allow for a roll back in case of an issue. The database is untouched. The restore db methods are behind the login.
There will not be a password or pin or any protection on port 8081 as there is nothing to secure.
You already are in control of when you do the updates, we have no means to push updates to your hub automatically.
There are plenty of ways to secure the hub on a lan for the hyper security minded, put it on its own vlan, lock down access to port 8081 at a route level... Even disconnect it from the internet, everything local still runs just fine.
It is not a security risk nor is it going to be password protected.
ooookkkeyyy.... well... I guess that's it...
Thanks!
Sorry, may I just ask, what was the point of adding User Security if you have all those other ways of securing the hub? I may just have misunderstood the feature and using it for what is not...
Well, people wanted a login to their hubs. So user administration gives them that so their hub can't be directly accessed on their lan.
We also have plans to do more with users but this was the first step.
Most consumer grade home lan devices are not secure. Take Hue or Sonos, both have ZERO security or authentication on the local LAN. Many others do as well.
We have multiple layers of security, most of which comes with the fact that an internet connection is not required for local access and zigbee and z-wave devices. Only need it to do updates, remote access via SSL endpoints via our cloud relay using OAUTH2 tokens to things like dashboard and maker API or Rule Machine cloud endpoint triggers. Or for cloud integrations, like Nest, Ecobee and others that need the cloud connection.
If all you have are automations that use zigbee and/or Z-Wave you can literally unplug the ethernet cable and everything that is set up will continue to run as is.
So you're saying being able to roll back firmware without a username and password isn't a "security risk"?
How is it a security risk? The database is not touched during the rollback process. You are in control of when and if you do updates and when you do roll backs. If you don't trust your network, the scope of the risk is limited to running the last software version... Once you have updated to 2.0.1 the only option is to roll back to 2.0.0 which both have user administration enabled.
What is the attack vector? Someone gets on your LAN... The worst they can do is roll your hub back to 2.0.0 and it still is password protected. If someone gets on your LAN, updateTool is the least of your worries.
I have a segmented IOT VLAN due to some of the security concerns you mention in previous posts above, however that doesn't negate the desire to have things as secure as possible. If someone gains access to this specific VLAN they more than likely will be looking for vulnerabilities in devices on that VLAN which in turn could give them access to my primary LAN given there is some connectivity between the two networks. This leads me to what happens if someone does find a security flaw in the HE software in the future that requires a firmware update to "fix"? If someone has free and clear access to roll back my firmware, then they can easily remove the security fix and potentially gain access to my LAN via HE.
The likelihood of this is obviously minimal but why take such a hard stance in saying there will not be "any protection on port 8081"? I get it, HE is probably more secure than half the other IOT devices I have out there but why not do it better than them? HE is well above and beyond in every other category, why not take the same approach with security?
FWIW I was a huge fan of seeing the user auth being added to the platform.
Download the Hubitat app
