So, I understand the concern about the Secrets file being plaintext, and the desire to store those passwords in a form to prevent accidental exposure. Let me throw a solution that some of the systems I support use, doesn’t require a bootup intervention, and at least adds some obscurity to the passwords. Is it a perfect solution, no, but it’s better than nothing.
To store the passwords, the system generates a unique and random key. That key is then stored in the database (storing it there makes it harder for a low to medium skill hacker to find it - on some of the systems where this is used it is combined with the Hardware MAC address, so you need both to decypher the passwords, but I wouldn’t recommend MAC Address here). Having the key in the database also means that it is backed up, and if a system is restored, it is restored as well.
The key is then used to encrypt the passwords for storage. When it’s time to decrypt, the system knows the encryption key, and can retrieve the password.
And the best part, it can be used anywhere passwords are stored, not just the Secrets file (which for this to work, there’d have to be an editor in the GUI that would then write the encrypted secrets file).
This already happens for many integrations that store secrets, FYI. I know i used this technique (with a library in core already shpiping) to store the private key of my own MPRIS integration.
The problem, as always, is that the encryption key for those secrets has to be stored on the disk of the home assistant machine, which means if that key is stolen along with the encrypted data, the robber can decrypt the secrets.
FYI it IS possible to fully encrypt an HA instance (just not HAOS one). My own HA instance uses full disk encryption. The drawback, of course, is that I must type a password on every reboot. For most, this is not an acceptable compromise. Solutions like Tang+Clevis exist, but it requires another device plus sophisticated setup, and theft of the Tang device is equivalent to theft of the password.
Of course, none of this protects against theft of secrets from the RAM of a running machine, which is rare but doable.
Thank you, I feel less alone. HA defends our privacy, and this is written deep in its genome. I don’t understand why these secrets are so easily accessible.
They aren’t “easily accessible” at all! Attackers have to physically steal a disk, or somehow break into the HA OS instance, to get at those secrets.
If on the odd case that you are running HA on a shared computer that has other users, and somehow HA secrets are stealable by those users, you have badly misconfigured the server.
If someone has hacked your computer or stolen it, you have much bigger problems than “my revocable Spotify API key was cloned”.
Analogy: Do you hang the keys for your front door when inside on a hook or put it in a vault everytime after use? Do you lock the front door while the keys are inside? If someone gets your keys because you left the front door unlocked, you have bigger problems.
That analogy doesn’t work, because it is actually recommended not to keep keys in easily visible and accessible spot near the frontdoor. At least before the current wireless methods this was one of the most common ways cars were stolen.
then secure your (wifi) network, mount HA hardware into some locked box (considering you afraid of family members) and done.
You can also go for disk encryption (not with rpi). Otherwise everyone who stole your HA will get access to everything.
As others said, encrypting keys doesn’t make sense if everything needed to decrypt it is stored at the same location.
And it really doesn’t matter it’s hidden somewhere in .storage or so. HA is open source. An attacker will know how to break it before he will eventually try to do so.
Another question is, if current HA, with no RBAC guarantees no access to configuration/sensitive files by other users.
I didn’t say you should advertise where your keys are. And no analogy is perfect. I was providing an analogy for the prior post and I think it’s relevant to that. All security in the end comes down to a source of trust, no matter how many layers you add.
Those who are concerned about keys hitting SSD unencrypted can always set up Home Assistant Core using pip or uv on an encrypted partition.
As I may have already expressed before, this is what I did. It’s a royal pain in the butt to keep up a system that way, but it does what it says on the tin — it’s always encrypted when off.
On x86-64 you could use TPM to auto decrypt the partition during boot. (Together with secure boot to ensure that the boot loader isn’t modified.)
This is slightly less secure than entering password at every boot, but prevents moving the drive to another computer to read the data from it. If you ensure that the boot is secured all the way to decryption (e.g. password in bootloader if you want to change kernel command line).
A pain to setup, but doable. I don’t think there is any equivalent hardware root of trust on Pis.
There is also the attack where someone uses freeze spray on the RAM of your running computer, and then extracts the ram and reads the encryption key out of it with dedicated hardware. Should you be worried about this? What about state level bad actors?
You need to figure out your threat model. Personally I’m ok with an unencrypted disk on my Pi. But my laptop I enter the password to at every boot.
