Security of hass.io

@Landrash raised some legitimate security concerns so I want to make sure that everyone is aware of them. I also added this as a note to the announcement post.

Hass.io currently can be controlled by anyone who has access to your Home Assistant instance. Since we support custom add-ons, this means that anyone with access can run any application on your machine. Do not connect your hass.io instances to the internet. This will be addressed in a future release.

The challenge here is that we want to make Hass.io secure by default. If it’s not secure by default, the chances are high that our users won’t secure it, connect it to the internet and the next IoT botnet attack will be powered by Hass.io.

I have some ideas to make it more secure:

  • Have users write an hassio password to the SD card when they are flashing the image. Require that password to access the Hass.io panel.
  • Do not allow the Hass.io panel unless a user has set a password in the config -> this is a chicken/egg problem because they need to access hass.io panel to add Samba or SSH add-on to access the config to add the password :thinking:
  • Add option to hass.io component to only allow commands from whitelisted IPs. (Not secure by default, still better security)

Feedback welcome.

What about including something like https://www.vaultproject.io ? Have the user create a secure vault as the first step. Then manage all secrets for everything in Hass.io through the vault?

1 Like

Another option is to have Hass.io ask user to create a password on initial setup and store that on disk. Probably easiest solution.

I think the best way is to not allow add custom component before user set here password.

Edit:
To ask for a password on first panel start is also a realy nice idea :thumbsup:

If we can read from the SD-card you could write it to a file after flashing the image. The boot partition is FAT32 and should be readable by most operating systems.

1 Like

Yeah, but that is only on ResinOS and not for a generic installation. It is also possible to use the generic Installation on raspberry if they don’t like the ResinOS. But we can make the installer to ask a password and write it to harddisk for generic Installation.

I like the idea that the user need set a password on panel before he can access to the hole panel. That make it portable and more userfriendly.

Maby we found a other solution but I think your and the idea from paulus are that one who we need to desicde at the end.

@balloob I think that password is only needed for access to store. The first front need not be passwordsafe?

Here is the concept:

  • We Support Password that can be set on Initial by user
  • We Support TOTP u.a. with Google authenticator
  • User can set password on hass config

Sorry for silly question, but what does “Do not connect your hass.io instances to the internet” mean exactly?

Does it mean don’t expose your rpi or machine running HA via DMZ, or opening the UI ports through the router? Or, only run with a reverse proxy to open certain ports? Or does it mean simply having it on your main subnet with internet connectivity? Of course these machines have to reach out to the internet to do base installs, apt-get etc.

When you are speaking of setting a password on the first start, are you speaking of the homeassistant password or of a distinct one for hass.io ? In other words, is it sufficient to set the password in the homeassistant configuration ?

Hass.IO is controll of it self. So you need set a password for hass.io but you can write that to hass configuration if you don’t want to use it every time. You can also use TOTP if you want more security.

Where is the configuration located ?

Fairly new to Hass.io but what is the current state of security? I was under the impression that since Hass.io is running in a docker through resinOS that it was actually more secure than other HA setups. I thought if someone was able to access your Hass.io, that’s all they would be limited to.

Yeah this is what’s preventing me from using HASS.io. Google assistant requires exposing to the internet and apparently HASS.io isn’t secure enough

Docker itself does not make something inherently safer. Access to HASSIO is access to the entire machine

I think this original discussion dates back to the early days of Hass.io (not really that long ago), and seem to focus on how they wanted to configure Hass.io security before making it available to others. It would be good if they closed it out with an update or as legacy info as it does seem to create uncertainty.

I used an encryption key to limit access to SSH and samba shares on my own network at home. I didn’t expose my Hass.io to the internet until I installed the duckdns addon with let’s encrypt. There is only one port redirected on my router to enable this (though I don’t use google home or Alexa).

I am not a security expert, but do these encryption features and services not provide adequate security?

1 Like

With these things covered, that leaves the web front end authentication and its strength or weakness.