Why so much dilemma with this? In first place if someone not desired enters or have access to your LAN network then you should be concerned, there is no change in the security doing a firmware downgrade, the database still intact. But if you have your hub without password then this not desired person could gain access to your home.
Don't give them free and clear access to your LAN.
Seems like you already have this solved.
So I don't really personally want to be so locked down so much that I don't have access to recovery tools when I need them most. Can't you just block 8081 and open it when you need to use it?
I have Insteon and while they were not secure in the past, they went to great expense, recalling hubs that didn't have the embedded wolfSSL. But, even today, if you have local access to my network, and know what you're doing, you can get the device ID of every Insteon device on my network and control all of them. Is this a major security flaw, no. I'm thankful for it in fact, otherwise I wouldn't be able to have local control of my Insteon gear from HE.
The scenario you're suggesting isn't beyond the realm of possibility, but I'd personally rather see the limited development resources stay focused on home automation feature enhancements. When the hub is at that mainstream consumer level, where networks are unlikely to have much security at all, then it's going to be a more pressing issue. Today, the relatively small number of HE hubs in the hands of hobbyists really doesn't warrant spending an immense amount of time on this.
Don't get me wrong, security should be first, and it isn't for a lot of startups that are putting their ioT devices on the internet. But that's not the same as what we're discussing here. This is trying to lock it down in every way possible and that's just not an appropriate move for a product that, while very good for its stage of development, is not ready to be 100% locked down.
I'll at least say this, nothing is no forever... It's been added to the feature request list... Might be at the bottom of the list, but its on there 
6 Likes
Thanks Patrick! that's all we wanted... for now... 
Agreed
Cool.
fwiw I see both perspectives as having validity. Considering we're still in the 1st year, I think it's completely fair to use the 80/20 rule, there's so much to do when starting from scratch. That said, hopefully some of the remaining 20% of concerns can gradually be looked at in time.
Just a side note, I updated to 2.0.1 this morning and still have 1.1.7.120 as a roll back option. I never installed 2.0.0.102. I went straight to 2.0.0.104.
You can roll back to 2 previous versions. So until your next upgrade, someone could indeed thwart your user login by rolling back.
Yes, Until I upgrade to the next release which I'm sure won't be long
Haha, yeah, like today with a hot fix...
5 Likes
Reading through the forums I found out about this other page that allows you to reboot the Hub.
Please add that page to the feature request as well, I think moving the reboot function inside this page after securing it would be the best idea...
I do not want to go back to the discussion of if this is really insecure or not, no point to that as it all comes down to each one's opinion on security, just leaving the comment here in case this feature request is ever considered. I will just say that being able to halt your home's automation at will is not a good idea for example for people using HSM with windows and door sensors and notifications, etc.
1 Like
The reboot url is already behind the login / security
Please don't take my disagreement as a slight. I have a very different view on HA at this stage of the game. I respect your point of view because we know the HA world needs to start getting a lot more security conscience as this industry becomes more mainstream.
But it is my belief, that if you are doing home automation at this moment in time, you are inherently exposing yourself to risk. This is why I have nothing that is life safety related dependent on my hubitat. Currently it only supplements these tools or provides an added level of convenience.
As such, it is my vote that we do NOT add the ability to reboot the hub behind another firewall. The ability to remotely reboot my hub is one of the features I love about Hubitat.
Again the above is simply my opinion and may be overruled by the majority...but I really hope that is not the case.
Stephan
I just did this and my hub restarted:
Invoke-WebRequest -Uri "http://ipaddress:8080/hub/restart" -Method Post
Not at all, that is why I said it all comes down to each one's opinion on security...
1 Like
do you have a login turned on?
Yes I do.
I just did a test using POSTMAN, a raw POST will not be authenticated.
I don't use windows, but I assume an Invoke-WebRequest opens or uses the default browser, which has an authenticated session.
Try logging out first and then do your test.
1 Like
...I just tried my Tasker reboot task and it failed.
Hopefully I can find a way to authenticate through tasker.
Even better, I just remoted to a PC where I have never used Hubitat from, to be sure I opened a browser and went to the hub and got the login page, closed it without logging in...
I executed the powershell line and my hub restarted.
So I did this instead:
$response = Invoke-WebRequest -Uri "http://ipaddress:8080/hub/restart" -Method Post
$response.RawContent
and I can confirm that indeed the page received is the login page, yet the hub does restart every time.
