Say you have a script or something that gets run in cron/task scheduler and it needs a password… say to ssh to a raspberry pi elsewhere in your house.
How do you save that password in a way that automation can access it?
Some ideas:
- Plaintext file. Not a fan because its sitting unencrypted on the box somewhere.
- Environment variable. Not a fan because its still unencrypted somewhere to someone on the box (albeit likely the same user or an admin).
- A secrets manager. If I use something locally like hashicorp vault or infisical, I can get to a point where a cli/api call gets the password. Though in this case I still need a vault password/secret to get my password. So I fall back to needing one of the above to get this to work.
If the secrets manager is easily available, the secret to get into the secrets manager is available as well leading to a feeling of security by obscurity.
If someone breaks into my system via SSH/etc. then they can get the passwords either way.
… How do people normally do this? I’m not sure I actually get anything out of a secrets manager if its local and I have the disk itself encrypted before login.
What actually makes sense at a personal/home scale?
(Edit: I know using SSH key probably is better for getting to the raspberry pi, but still the question is the same idea).
I was thinking of the same thing: unless you’re running an enterprise load where you need to keep secrets like they keep it in the industry, filesystem encryption should be OK for the most part
I guess at the end of the day there is also a root of trust. In an enterprise setting a system giving out certs could be compromised and give out certs to the wrong people/machines. In a home setting, the machine being compromised has a similar affect.
Funny enough, I thought of using a USB stick or something as a physical security key, using that for a vault, then having secrets in the vault… but then realized I’d have to leave it plugged into the server, making it so anyone with server access would get the password anyways.
Makes me think that everything is security by obscurity at some level. The more obscure: the more ‘secure’.
It’s kind of like how an SSH key is generally considered more secure, but if I used password authentication and had a file with a 512 character random password, it would be more/less the same thing. Either way, we have the key in a file.
Yes, there has to be a minimal level of trust between the server and devices/users. You’re level of security defines what point the computer decides “yep, that’s good enough, I can trust this is the real user accessing me.” A true, perfectly secure system has no access, it’s a black box that nothing can interact with, because it can only trust itself.
At some point you have to trust yourself not to mess up too bad, you are the weak point in security, since I’m assuming you’re the only one who’s accessing the system right now.
I personally use plaintext password files, with appropriately managed permissions (only the owner can see or read the file.) As long as the user login is secure, and root/admin access is secure, I feel comfortable that no one but me can access the credentials. To manage remote access to the system, I use hardware (YubiKey) to store my SSH keys, with a PIN code lock that wipes the keys if entered incorrectly 5 times. I don’t have any government agencies coming after me (as far as i know) so no one has a practical way to extract the keys if the device were stolen off me, and the PIN retry limit prevents brute forcing. I trust myself to manage these hardware keys appropriately.
*Edit: to add to the “appropriately managed” bit there, each sub system (home automation, file server, media hosting, etc) should be properly containerized or isolated (using different user accounts) so that if one service is compromised, the others are still somewhat protected. *
Physical access to your server is endgame. If an attacker can physically mess with your system, you’ve lost, and that can only be fixed externally with home security improvements. A skilled attacker doesn’t need your ssh tokens to gain access if they can plug a keyboard into the server itself. I’ve also seen a demo of a neat little kit the feds use to seamlessly move a computer power cord from the wall to a portable battery pack, so they can simply walk out, with the device still powered up, and do what they want to it back at home base (it’s used mainly for raids on various computer fraudsters, but still, it exists, and can be used on you). I trust myself not to do stupid stuff that gets me targeted by a hacker group, or raided by the FBI.
Something less targeted, like a burglary (not focused on your server), can be protected against by disk encryption. I don’t use any disk encryption, but I probably should. I like the idea other user’s wrote down here, of using a TPM module to store disk encryption keys, so it can detect if the hardware or OS changed between boots and deny decryption. I’d also take it one step further and encrypt the data/password files with an encryption method that requires someone to log in and type a password, that way if someone were to steal the device and power it up elsewhere, the passwords are still safe until you OK it, essentially authorizing unexpected reboots, at the cost of having to log into the server every time it starts (not fun if you’re doing maintenance.) if you do this bit right, you don’t have to trust yourself to do anything but remember the password.
Sorry about the length there, but security and access management is a complicated topic, so it requires a lot of talking. Hopefully it helped!
I think you hit the nail on the head with the true security being black box. The moment I need access, I’m making a hole.