WTH 2025, A Secret is secret !Why are passwords in plain text in the config_entries file?

Month of "What the heck?!"
1

Although we all know that password encryption is a complex topic in Python environments. Let’s protect ourselves. of a theft of equipment and overly curious minds Let’s propose a simple Fernet encryption and decryption API based on config entry id configuration and why not a nice self.hass.encode() and self.hass.decode() To use at your leisure in our config_flow and other coordinators

2

I believe the reasoning (every time this is brought up) is that the system needs the decryption key or it can’t access the stored passwords. If the system has the key then it is trivial for a bad actor to obtain the key from the system too. This encryption would lead to a false sense of security.

Secrets are only there to prevent uploading sensitive data to GitHub when used for backup, it is not meant to be a secure store.

12 Likes
3

You get burgled and your Pi is confiscated, our thief gets the SD card and searches through the files, what do you do?

4

The thing is, if HA can auto-decrypt them then so can the thief. You’ve gained an illusion of security, and that’s worse.

6 Likes
5

What is possible is to use a “storage” for secrets that needs to be unlocked at boot time with a password or biometric sensor. Then you must make sure that after a reboot you have access to HA to unlock the “storage”.

But as long as HA is running the data is open for any hacker that has gained access to your system. So your are only protected in case of theft of the hardware.

6

Windows, Apple, Linux, and many other systems store encrypted data in such a way that bad actors cannot get at it. This is not rocket science and can be done. HA could even leverage the secure storage mechanism offered by the host OS. I think that keyctl provides the interface on Linux. Windows and Apple must have similar facilities.

1 Like
7

Those systems usually require a password to unlock which is used as the encryption key. It’s only secure if the key isn’t stored on the system and needs to be entered or provided in some way to unlock the system.

It would be very inconvenient to require a key for Home Assistant to start every time it reboots, updates, or the system looses power to unlock the encrypted storage.

4 Likes
8

But that is the beauty of leveraging the OS facility. You only have to prove your identity to the OS. When you log on or to get out of the screen saver. Doing those things unlocks the keystore.

9

So you don’t want your automations to run unless you are permanently logged in somewhere?

No thanks. I like my automations to run 24/7 unattended.

3 Likes
10

Actually, that and more can be addressed. The developers of keyctl and the kernel features knew of all these needs and more. It can even use TPM for hardware level security.

If I had the time I would build the interface. People could use it if they liked.

11

If I had the time I’d build a castle. People could use it if they liked. :roll_eyes:

4 Likes
12

I imagine it would look like this one

image
image570×855 88.1 KB

1 Like
13

I would take some level of security over none at all.

It’s like locks on doors. They only keep the honest people out. But I would never leave my front door unlocked. The secrets.yaml file is like having an unlocked door with a sign on the front saying “Treasure inside”.

Encryption of the secrets.yaml file would add a degree of difficulty to stealing your passwords that would stop most casual thieves. Any inferred false sense of security could be addressed by clearly stating that using this option only makes it hard to see your secrets, not impossible.

2 Likes
14

Let’s not talk about encryption for a few days

3 Likes
15

OK, Deal :laughing:

1 Like
16

This only stops the least sophisticated thieves. It would also lead to bad outages if HA restarts and the user isn’t available to physically interact with the HA box or VM.

1 Like
17

The only secret in my secrets is my wifi details on my password protected laptop. If they have broken into my home then wifi details are the least of my worries.

1 Like
18

This is the key.

You’re talking about desktop systems. Servers don’t have logged in users (typically/normally).

Sela.

2 Likes
19

I would not use such a setup for the reason you wrote (physical access at boot time).

But what would a more sophisticated thief do to overcome the password issue?