Protected web interface?

📢 Feedback Feature Requests
1

As it stands now, it appears the Hubitat Web interface is open to anyone on the same network as the hub. Unlike Home Assistant (and maybe Vera, though I didn’t use it long enough to remember), there is no password protection or similar, so more or less anyone at your house can go through and modify your devices, automations, hub, etc. and, intentionally or not, possibly change or break things. (EDIT: And of course, to compare it to SmartThings, SmartThings requires a username and password login to the app with, of course, no Web interface.)

Is there a different, less-obvious way around this problem? (Obviously segregating the hub to a special vLAN with the right configuration would be one way to help mitigate this problem, but I don’t think most people are going to do that, and it of course makes it more difficult to access than a simple password would.)

I also notice that the traffic is currently HTTP. If there were login information transmitted, I’d obviously prefer HTTPS (even on my own network), so I guess that would be another feature I’d want with this one.

If none of these are possible for some reason, even a Hue-esque “username” in the URL that needs to be on a whitelist would be better than granting wide-open access. Without a physical button on the device itself to press to authorize this creation, it would probably be more difficult to implement, though the initial “portal” registration could probably handle the initial creation of this.

Someone let me know if I’m missing something here; otherwise these are just a few ideas I have to keep my hub from being wide-open on my network. :slight_smile:

9 Likes
2

I second this. At least password protection please.

3 Likes
3

Agreed some kind of user perms, you could then allow different perms to different dashboards / items.

4

Yes please add password protection.

1 Like
5

It’s on our list to get done. Won’t be too long.

3 Likes
6

Just one dissenting view… I prefer the trade-off of security vs. convenience on the side of convenience. If you go the way of onerous authentication, press make it optional.

2 Likes
7

That's the plan.

5 Likes
8

Also +1 for this. I was able to setup a reverse proxy server for SSL encryption but having some form of native authentication would be a big plus.

1 Like
9

+1 on this... somewhat of a major security concern not having a protected admin interface.

1 Like
10

This is in development. We understand the need, and will offer this once complete.

3 Likes
11

+1 This can control my security system and door locks it must be secured.

1 Like
12

@bravenel
As a stop-gap, is there any way to setup PiVPN / OpenVPN on Hubitat so it's only accessible via a secure VPN connection? As an added bonus, it would allow secure remote access to our networks from a low-power device as well.

13

I just use the OpenVPN server in my ASUS Router. It works great and gives me fast, secure, remote access to my entire home network.

Having the hub have secured access to the web admin page is still a high want on my list to keep my kids off the hub.

1 Like
14

Now that user management was implemented, is there a plan to add support for SSL?

An auto generated self signed cert would be ok but ideally with the option to upload your own...

15

I think it's not really necessary to provide native SSL support as long as reverse proxying is properly supported.

I set up a reverse proxy to provide access to and protect the various web interfaces I have in my home network. Hubitat is one of these applications. Hubitat has its own subdomain (habitat.mydomain.com), and that’s mostly working fine, but there are a few functions that seem to use hard-coded URIs, i.e. Hubitat’s internal IP address instead of a relative path.

I can access Hubitat via https://hubitat.mydomain.com correctly, but for all apps that use child-apps, i.e. Motion Lighting Apps, Rule Machine, clicking “Create New Rule”, redirects me to https://<internal.ip>/installedapp/configure/489 - which of course doesn't work because the IP address is only reachable from inside the network and Hubitat keeps the URL scheme (https vs. http).

Would be great if the dev team could look into this.

Thanks,
Jan

16

Be careful, do not think a reverse proxy by itself will protect you from hacking if you are going to expose Hubitat to the internet, other than adding the SSL layer (which does not fully work as you state) it is no different than opening a port in your firewall.

As soon as the endpoint of your reverse proxy is found by automated script robots your system will get pounded until a security hole/vulnerability is found or an username is brute forced. Reverse proxies pass on almost all security vulnerabilities unless you also have some kind of application gateway firewall with complex rules, but those generally need a lot of work to get everything working properly.

I believe the only recommended way to access Hubitat remotely is with a VPN.

17

Can you double check, the paths and redirects are all relative to site root. There are no absolute paths that hard code hub ip that I am aware of.

18

Sorry it took me a while to reply. Yes, I'm absolutely sure. I'm only aware of one place where an absolute link seems to be used, and that's - as I wrote before - when creating new rules.
The link itself - example: https://hubitat.mydomain.com/installedapp/createchild/hubitat/Button Controller-1.6/parent/199 - is relative as can be seen here:

image

However, from there, a redirect to https://hubitat-ip/installedapp/configure/518/mainPage takes place, and that, of course, doesn't work.

19

I can assure you there are only redirects that are relative to the host. Because it happens server side we have no idea what your reverse proxy is. Not something we can fix or support.

20

I experimented a bit with the reverse proxy settings. Seems like Hubitat relies on some header that needs to be passed upstream by the reverse proxy. This is only relevant when creating new sub-apps, e.g. new rules in Rule Machine (see above).

In caddy (which is a great web server and reverse proxy by the way), this can be achieved with the transparent argument:

https://hubitat.mydomain.com {
  proxy / http://hubitat-ip {
    transparent
  }
}