Environment variables are generally fine for secrets. Environment files are problematic. Modern systems that inject secrets into the environment launch the program itself.

▲

IanCal a day ago | parent [-]

(pre-caveat thing to not be massively annoyingly pedantic throughout, I'm not a security buff and I know who it is I'm talking to, I'm not trying to correct them)

I'm not sure I get the difference - the issue I would have thought was having the system code have access to the secrets themselves? Env file vs env vars injected at runtime seems the same there - either can be exfiltrated. The difference would be having it injected when used.

Is the problem with files about what happens outside that, being committed, etc?

▲

tptacek a day ago | parent [-]

Everything can be exfiltrated. If you never store the environment in a durable file, it's not meaningfully easier to exfiltrate from the environment than from process memory. Most of the wisdom about the insecurity of environment variables falls out of people setting them in .profile or in .envrc files --- that's very bad, yes, as are configuration files (the thing 12 Factor Apps was responding to).

The headline here is that there's no reason to believe "environment variables" were the reason this data was breached; presumably, the database those variables came from was what actually got hit.

▲

trollbridge a day ago | parent [-]

You can say "everything can be exfiltrated" but capturing my PC's password is about nigh unto impossible. The only way it can be captured is if a program has active control over the keyboard controller/associated drivers when I type in the password to unlock it.

These problems were all solved a long time ago.

▲

justincormack 14 hours ago | parent [-]

Plugging a keyboard into your Railway instance every time you start on app is not going to give you a great SaaS experience.

	▲	NichoPaolucci 12 hours ago \| parent [-]
		I think some of this conversation is circling around the concept of 'allowable risk'... We have a couple of VMs that are not mission critical, and they don't hold sensitive data. We just inject the secrets into the runtime. Access to those machines is restricted to a single IP, there's not much more protection in front of them. A meaningful attack on one of those machines would require a LOT of effort, and almost nothing in return. Some systems don't NEED to have government level security, as a developer it's my job to provide the best solution for each scenario. (IE, I wouldn't put 12 security cameras and an armed guard around a fruit stand, but I might around a jewelry store)