WTH: Protect content of secrets.yaml (or make it unnecessary at all)

Month of "What the heck?!"
#1

Everything’s said already, e. g. @ Secrets.yaml security.

Having so critical information in plain text is a no-go from a security point of view. Once I have access to a HA instance the first thing I’d always look at is this secrets.yaml file.

Why not hashing stuff after providing it in plaintext once - or finding other smart ways to in the end avoid storing secrets permanently in plain text.

To every potential new HA user reading this and potentially being scared of it cause we have 2022: overall security of HA is great! It’s only this little legacy piece. Start using HA :slight_smile:

#2

Completely true. But, apparently, it’s no priority for the dev’s of ha. Sadly enough

#3

This has been brought up many times before. Let me start by saying, unlike what you describe in your OP, this is not legacy. Same with the security comment in the second post, not being a priority is pretty much huge bs.

We are absolutely welcoming any architectural proposal that truly is able to do this correctly, without providing a false sense of security.

I’ve been with the project for 5 years, nobody has succeeded in that. The part that did try/provide some sort of thing has been removed as they didn’t get used, didn’t work as expected, or provided a false sense of security.

TL;DR: This is one of the obvious things that sounds logical, however, no one has been able to provide even a description of a solution.

…/Frenck

PS: The only reason for the existence of secrets.yaml at this point, is because of history. Allowing to share your configuration on, for example, GitHub and being able to simply exclude your credentials (that is the history behind secrets.yaml).

6 Likes
#4

Thank you for taking your (rare) time and for explaining. Only here for 2 years, wasn’t aware of the history of this file.

Totally get the points mentioned, implementing a secure way of handling those access information is anything but trivial. Putting it in a single file for sharing the rest of a configuration is a good thing on the one hand, creates a honeypot (oh no, it really is a honeypot, no fake honey in there :slight_smile:) on the other hand.

Because of

I just wanted to add that my “legacy” piece refers to what I experienced during the last, let’s say 1,5 years: the need for storing access information in that file decreases with every integration being available in the UI. That’s a great development! :tada::partying_face: Because that reduced the content of my secrets.yaml a lot (remaining candidates e. g.: InfluxDB - Home Assistant, Nextcloud - Home Assistant, some TTS services like VoiceRSS - Home Assistant).
So “legacy” refers to the way we were used to integrate things in the past:
One had to use this file a lot, but nowadays with all the integrations being available in the UI, it’s not that important anymore. No offense. :slight_smile:

Reading through my own comment I must admit: that file is not that important anymore, therefore the need for optimizing its handling plus the experience with the difficulty to do this… I think I would look forward (not back) and hope

  • the remaining integrations will be available via the UI some day and
  • the way integrations store their credentials (/config/.storage/core.config_entries) does a better job in terms of protection → but I think it’s the same issue, just another file…
#5

? How is it a better job? It’s a plaintext file with all your credentials.

If anything I’d say your WTH should focus on that. secrets.yaml is basically a strange form of blueprints before blueprints existed. When the only way to share your config was to copy and paste the yaml and then people could find the secrets and fill in the blanks with their specific info. Now we have a way to actually provide real fill in the blanks as inputs and give people selectors that guide them to picking something that works right in the UI.

To be clear, frenck is totally right about all the challenges here. But if anything should be encrypted on disk these days it’s the config entries file more then secrets.yaml.

#6

even if it’s encrypted, home assistant is open source. Anyone can get the encryption keys… making it pointless to even encrypt it.

#7

That’s exactly what came to my mind after having a quick look how/where credentials nowadays are likely stored and stumbled over the named config entries file. Just replace all secrets.yaml file sections, same reasons go over to that file. Likely much more interesting to steal nowadays than the secrets.yaml.

#8

Yea I mean like I said, the challenges frenck mentioned are real. I just mean if you’re going to ask for one file to be encrypted on disk it should be config entries over secrets.yaml.

1 Like
#9

I’m not into implementing security algorithms into open source projects. But there are other FOSS like GitHub - nextcloud/end_to_end_encryption: Server API to support End-to-End Encryption who manage to even implement E2EE.
What I’m saying: open source is not a no-go for enhanced security.

#10

that still requires you to store the encryption key which will be plain text… What you’re asking for requires closed source in some way shape or form. It is 100% not possible in HA unless they close source an entire section.

Step 1 of that lib:

#11

Pointless to use encryption in open source??
Really???

2 Likes
#12

Yes really, when it is the software itself that needs to login to a protected service without user intervention. Because then whatever the software does to login can be read and reproduced, provided you have access to the same resources that the software has (in this case secrets.yaml and the code of the software). Only when there’s information that is not accessible wil there be any real security. But it would mean that home assistant cannot reboot without user intervention.

#13

Yes really.

#14

what about storing secure key needed for secure data decription on external storage (usb stick, other local storage)?

isn’t the ptoblem the fact that all core components have access to the whole configuration, security data is part of? I’m almost sure it was the case year or two ago when all components was relying on yaml config. Maybe it changed with config in .storage

#15

Ok,
So all those open source projects are insecure…
Why open-source encryption is better for your privacy | Proton.

#16

This just shows that you don’t understand how it works. They all require a encryption key that’s stored in plain text somewhere on a system. Anyone that has access to that system can read the encryption key and get then access the information.

Home assistant will have the encryption key and secrets file on the same system. Making it 100% pointless.

Closed source solutions have the plain text encryption key imbedded in their binaries and the encryption methods are also in the binaries. Both which cannot be read or accessed by the public. A person who works at the company and develops the software could access your encrypted files if they wanted to… because they have access to the source.

TLDR: Encryption only works when people don’t know how it’s encrypted. As soon as you know how it’s encrypted, it’s not safe and it’s just an illusion.

2 Likes
#17

What about those hashes…

#19

The setup of all theses services requires an encryption key that’s stored locally somewhere. That’s the first part of this setup. Home assistant could use these, but guess what? It needs to store the encryption key, either in source or in a storage file…

And if it’s hashed, home assistant is open source, so you can see how it’s hashed… to unhash it.

1 Like
#21

It really depends what problem we are trying to solve though right @petro ?
If this is about secrets.yaml ending up on Github, then the solution is simply to use the installation id and the userid of the first user as the salt for the encryption key.

If this is about preventing nosy people who have brief access to your home assistant config physically - then the above still applies, because reversing the encryption even knowing exactly how it works (which is unlikely, when a kid, or friend happens upon the secrets file) - is not trivial without also being a coder.

If this about preventing 3rd party components and integrations being able to get access to passwords, that’s a much larger problem, and doesn’t just apply to secrets.yaml

1 Like
#24

That would work for github only, yes.

You can just load the files into your own HA. At that point, they have access to your system, all they need is that information. Simply cloning the drive would gain access.

That’s the whole point of this. If they have access to your system, then it’s already too late even with the encryption. That’s why it’s pointless.

If the goal is to stop accidental access to secrets on a github push, sure this will work. Anything else, pointless.