Why is secrets.yaml in plain txt? and not hidden/encrypted

Configuration
1

new here, but trying to organize as neatly as possible…

Please help me understand why it is safer to use secrets.yaml to store passwords etc, when it is in plain txt? Somehow it seems very silly to have all secrets out in the plain view, all together at that.

Is there no way to hide this plain txt info?

Cheers,
Marius

2

secrets.yaml is to prevent accidentally sharing passwords/api keys when sharing config files. It is secure only in the sense that it should only ever be accessible locally.

If you want encryption, look into implementing keyring or credstash. (see here)

3

thx.
saw that before but thought id ask first :wink:
is it any good setting up the keyring, as it is done outside of Hassio? Credstash seems somewhat easier?

Anyways,
Will follow your advice and study some more…

Cheers,
Marius

4

Unfortunately I couldn’t tell you. I looked into it but ended up just using secrets.yaml as I am only storing API keys (something that can be regenerated) and local passwords only (which means the attacker would have to physical access to my computer/network to use them anyways).

5

It’s been discussed before.

There is no point in not using plain text. You can secure the file from casual viewing through file permissions. Beyond that, for Home Assistant to be able to use the secrets, it has to be able to decrypt it automatically. For that to work, it has to have the decryption built in, which anybody can then use to decode the files.

Secure the host, and you don’t have a problem. If you haven’t secured the host, well, then you’ve got a problem regardless :wink:

1 Like
6

thanks,

other than installing all in https://www.youtube.com/watch?v=BIvQ8x_iTNE and using a password for the interface, would you advise on added security?

how to secure the yaml-file permissions from within Hassio?
thanks,
Marius

7

There’s a few threads here, but I’d summarise it as:

  • Run it on a dedicated system if possible
  • Keep your system up to date
  • Ensure that the home directory for the Home Assistant user (usually homeassistant), and everything under it don’t have world write, ideally no world access at all (sudo chmod -R o-wrx ~homeassistant)
  • Don’t set a password, or add a shell, for the Home Assistant user
  • Ensure your password is randomly generated, and long (12+ characters), and you don’t use it anywhere else (use a password manager)
  • Enable the IP ban option, and set the failed logins to something that works for you. I’d whitelist your LAN IP range, and set the failed logins to something low if you’re using a password manager (one if you’re paranoid, 2 or 3 otherwise)
  • Consider running a VPN for remote access, so that the only thing accessing your system remotely is for OwnTracks HTTP, Google Assistant, etc.

Now, I don’t set a password for the front end, or use an SSL certificate inside Home Assistant. I hand those over to an NGINX proxy, so that my “internal” access is open, and my remote access requires a username and a password. That’s a trade off, I’ve added some complexity, but made it harder to brute force/guess the authentication details.

2 Likes
8

20 posts were split to a new topic: VPN and Home Assistant

14

It should be possible to instead encrypt values in place in the yaml files, though you’d have to make homeassistant unencrypt at load time of course.

Puppet’s hiera-eyaml made me think of this: https://github.com/voxpupuli/hiera-eyaml

A quick google search also turned up: https://github.com/deanmao/secure-yaml-config

15

Well the password for Home Assistant is stored in your browser in plain text too, so why not…

:joy: :sweat_smile: :cry: :sob:

16

never do that with critical passwords…

17

I’m new to HA and trying to figure out the most secure options. Are you saying that the password to access is stored in plain text so all the other efforts don’t matter?

18

In the browser, yes. So if your browser is compromised then that password is compromised (along with all your other browser data).

19

Ok. So what is the security recommendation to avoid that?

20

Don’t use a web browser :wink:

The same advice you’ll always get

  • Keep the browser up to date
  • Don’t install extensions you don’t need, and only install them from official sources
  • Don’t install untrusted software
  • Be careful where you browse
2 Likes
21

It looks like the keyring option has been removed from the docs. Is there a better way to do this now? It still looks like plain-text secrets.yaml is the only method described in the docs.

22

Keyring is only an option if you have a pure Core install method, since everything else runs in a Docker container.

As long as your network isn’t hacked, or you don’t publish secrets.yaml to GitHub, there’s no security issue here.

23

As long as your network isn’t hacked, or you don’t publish secrets.yaml to GitHub, there’s no security issue here.

Hacking the wifi isn’t the only attack vector. Someone could physically break into my house and steal the Raspberry Pi. Or a malicious add-on could upload secrets.yaml. Storing secrets in plain-text extends the scope of what an attacker could do, and is generally considered a bad practice. I understand it may be a low priority, but I think it would be a good idea to use encryption in the !secrets config system.

24

Let’s say that secrets support encryption.

HA has to be able to decrypt that, without your input, to be able to use it.

At that point, given that HA is open source, any malicious addon/integration could also do that. Any attacker who broken in and stole the Pi could also do that.

You’ve gained nothing but the illusion of security.

25

If there was an interface built into to the !secrets pattern then the community could add support. Things like 1password local resolution via connect-api