upvote

points

by numbsafari6 hours ago |
comments
upvoteby skinfaxi5 hours ago|
next
[-]
> Use environment variables to point to where secrets are located, not to store their values.

Now your apps need to be able to read the secret that is pointed to, as opposed to the task runner populating the secret and the app would not know about the details.Not to mention the changes it entails to development.

reply
upvoteby esseph1 hours ago|
parent|
[-]
> Not to mention the changes it entails to development.

Oh no, guess they'll have to hire developers that can adapt!

reply
upvoteby jrochkind15 hours ago|
prev|
next
[-]
It doesn't sound like they got them via a shell environment, they just hacked into the place that stored them. If the place you store secrets can be hacked into, it doesn't really matter if they are injected into environment variables or not.
reply
upvoteby atherton940274 hours ago|
prev|
next
[-]
How does this help? If your container gets compromised it's trivial to exfiltrate the secrets.
reply
upvoteby trollbridge1 hours ago|
prev|
next
[-]
Or we could just use our operating systems for the things we do well, and have a service to send our API calls to that inserts the appropriate token.

I don't have to enter my Mac's password every time I open an app.

reply
upvoteby tptacek6 hours ago|
prev|
next
[-]
Environment variables are generally fine for secrets. Environment files are problematic. Modern systems that inject secrets into the environment launch the program itself.
reply
upvoteby IanCal5 hours 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?

reply
upvoteby tptacek5 hours 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.

reply
upvoteby trollbridge1 hours 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.

reply
upvoteby zaik6 hours ago|
prev|
[-]
systemd makes it easy: https://systemd.io/CREDENTIALS/
reply