Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Do not use secrets in environment variables

nodejs-security.com

Post reply on HN
Print view View original

81–90 of 96 posts

Re: Do not use secrets in environment variables

#81

Post by sshine »

causal wrote: post #33
dolni wrote: post #18

This article has about as much insight as I would expect from a "nodejs-security.com" article. This article spends a good deal of time conflating two things: putting stuff in .env and using environment variables. The application-parsed .env file is one of the most poorly thought-through ideas that has taken hold in modern application development. It takes something you can do in literally a couple lines of shell (as…

Also annoyed that the title has > and here's how to do it better And then basically just says go use a vendor solution. Cool.

Yeah, equally disappointed.

I know vendors secret stores are better.

But what do I do that isn’t vendor-locked and is remotely as simple as environment variables?

Re: Do not use secrets in environment variables

#82

Post by cpill »

thayne wrote: post #65
mbrumlow wrote: post #42

Don't use secrets in environment variables, but use this secret in environment variables, but this one gives you access to all secrets. Things like vault which was suggested still requires you to pass the vault token in to your app somehow. And even then if your application does not have direct vault support you will still be using vault to supply secrets via environment variables, its even the recommended way with N…

> Things like vault which was suggested still requires you to pass the vault token in to your app somehow. And even then if your application does not have direct vault support you will still be using vault to supply secrets via environment variables, its even the recommended way with Nomad and their template system. Indeed. But ideally the "somehow" that you pass that in is not an environment variable. Maybe somethin…

I'm sorry, but is there any data on how many leaks there have been because of .env files vs whatever people think it's even more safe?

Re: Do not use secrets in environment variables

#83

Post by thomascountz »

Jakob wrote: post #52
dolni wrote: post #18

This article has about as much insight as I would expect from a "nodejs-security.com" article. This article spends a good deal of time conflating two things: putting stuff in .env and using environment variables. The application-parsed .env file is one of the most poorly thought-through ideas that has taken hold in modern application development. It takes something you can do in literally a couple lines of shell (as…

As middle ground for small scripts I like implementations like the one from 1Password: The environment variables contain the path to the secret: export DB_PASSWORD="op://app-prod/db/password" Calling the script with `op run scriptname` replaces the secret path with the actual secret after authentication during runtime. This way you can commit the file but people still can use their own passwords locally without savin…

For Mac, I use `security set-generic-password` and `security find-generic-password` to manage secrets using Keychain.

Inspiration here: https://gist.github.com/bmhatfield/f613c10e360b4f27033761bbe...

Then you can use it like this:

export OPENAI_API_KEY=$(keychain-environment-variable OPENAI_API_KEY)

Re: Do not use secrets in environment variables

#84

Post by mbrumlow »

bogantech wrote: post #75
mbrumlow wrote: post #42

Don't use secrets in environment variables, but use this secret in environment variables, but this one gives you access to all secrets. Things like vault which was suggested still requires you to pass the vault token in to your app somehow. And even then if your application does not have direct vault support you will still be using vault to supply secrets via environment variables, its even the recommended way with N…

> Don't use secrets in environment variables, but use this secret in environment variables, but this one gives you access to all secrets. Not much use to an attacker if the token / approle is restricted to a specific IP / EC2 instance id. Auditable too

Maybe all your secrets should be node locked …

Re: Do not use secrets in environment variables

#85

Post by cbsmith »

dolni wrote: post #18

This article has about as much insight as I would expect from a "nodejs-security.com" article. This article spends a good deal of time conflating two things: putting stuff in .env and using environment variables. The application-parsed .env file is one of the most poorly thought-through ideas that has taken hold in modern application development. It takes something you can do in literally a couple lines of shell (as…

Yeah, there was a ton of wrong here. You captured much of the highlights.

I now understand why some developers tell me they think using environment variables for secrets is a bad idea.

Re: Do not use secrets in environment variables

#86

Post by [deleted] »

outworlder wrote: post #73
dolni wrote: post #18

This article has about as much insight as I would expect from a "nodejs-security.com" article. This article spends a good deal of time conflating two things: putting stuff in .env and using environment variables. The application-parsed .env file is one of the most poorly thought-through ideas that has taken hold in modern application development. It takes something you can do in literally a couple lines of shell (as…

I had to do a double take and confirm the article's date. It talks about, say, restarting servers(implying downtime) and going to each one of them and updating one by one. If in 2024 you are still treating servers as pets, you are still subject to outages if a single machine dies, and you are still manually configuring them, you are doing everything wrong. And that's before we consider that most of the advice would n…

[deleted]

Re: Do not use secrets in environment variables

#87

Post by cwbriscoe »

hinkley wrote: post #56
stackskipton wrote: post #15

Earlier quoted context omitted.

SRE here, most of time when that happens, it's people leaving .env in git where it's not ignored and build process just does COPY * * to runtime environment. EDIT: Or it's just small time developers who don't care about security and ship whatever works.

Hidden files get checked/built in all the time. Too many people don’t think to look for them.

That is why I like "Allow Listing" in my .gitignore file. Much harder to add stuff by accident.

# Ignore everything

*

# But not these files...

!/.gitignore

!*.go

!go.sum

!go.mod

Re: Do not use secrets in environment variables

#89

Post by hinkley »

cwbriscoe wrote: post #87
hinkley wrote: post #56

Earlier quoted context omitted.

Hidden files get checked/built in all the time. Too many people don’t think to look for them.

That is why I like "Allow Listing" in my .gitignore file. Much harder to add stuff by accident. # Ignore everything * # But not these files... !/.gitignore !*.go !go.sum !go.mod

I do the same. But as I do it my mental image of myself is of someone holding their nose and typing one handed.

It’s the least shit solution, but it’s definitely a shit solution.

Npm has another way to default exclude but I don’t think git does, and if docker got one I don’t recall what it is.

Re: Do not use secrets in environment variables

#90

Post by ocodo »

thomascountz wrote: post #83
Jakob wrote: post #52

Earlier quoted context omitted.

As middle ground for small scripts I like implementations like the one from 1Password: The environment variables contain the path to the secret: export DB_PASSWORD="op://app-prod/db/password" Calling the script with `op run scriptname` replaces the secret path with the actual secret after authentication during runtime. This way you can commit the file but people still can use their own passwords locally without savin…

For Mac, I use `security set-generic-password` and `security find-generic-password` to manage secrets using Keychain. Inspiration here: https://gist.github.com/bmhatfield/f613c10e360b4f27033761bbe... Then you can use it like this: export OPENAI_API_KEY=$(keychain-environment-variable OPENAI_API_KEY)

as a cross platform alternative, I use pass (https://www.passwordstore.org)

    export OPEN_API_KEY=$(pass show open_api_key)
Post reply on HN