Storing secrets in the process env variables is risky

[eladchen]

I really like the solution offered by dotenv vault, just not as advertised.

Storing secrets in the process env variables is risky, it allows 3rd party modules
which run on the same process access to read the secrets..

As an architect in a tech company I'm considering using this tool like so:

• Create a js script that DOES NOT use any 3rd party modules
• Load the env variables using dotenv
• Flush the env variables needed by the app to a file and exit

This will result in a file with secrets existing on the disk.

The other part would be to start the actual process, init a module which will read the file and
delete it from the disk, thus it cannot be accessed by a malicious 3rd party module, whilst ensuring the secrets
are only available via dedicated module api.

WDYT?

[motdotla]

This will result in a file with secrets existing on the disk.

This has one downside. For server environments that have ephemeral file storage (like Heroku and many others) you can't guarantee the file will always be there. For other deployment environments like serverless, you can't always write to a file. They don't allow it.

Instead, maintaining the encrypted file in your codebase guarantees it will be available to all infra types.

Storing secrets in the process env variables is risky; it allows 3rd party modules which run on the same process access to read the secrets

This is a good thought. They only exist during that process (and are cleared when the process shuts down), but yes, if a 3rd party accesses that process somehow, then it can slurp them up. This is rare and means you have a worse intrusion (like a compromised node module or server), but I agree with the point.

What if we added the ability for you to pass your own target that should be written to - rather than process.env?

https://github.com/motdotla/dotenv/blob/master/lib/main.js#L188

We recently built the mechanism to do to this (https://github.com/motdotla/dotenv/tree/master#populate). We would just need to bubble up the option to config. Something like this:

const target = {}
require('dotenv').config(target: target)

console.log(target) // values from .env or .env.vault live here now.
console.log(process.env) // this was not changed or written to

What do you think?

[eladchen]

P.S The app.js or even dotenv itself could delete the file one the new process spawnd, this will ensure no malicious 3rd party modules scans/dumps the file system

[motdotla]

Ok, interesting. With 16.3.0 (just released) supporting options.DOTENV_KEY, you could optionally do this:

const result = require('dotenv').config({ processEnv: {}, DOTENV_KEY: 'dotenv://:key_cd9fe909e1adf109873d5117c3f4beda33a9a8006f4eaeb73a2a0d21bab0cbd4@dotenv.local/vault/.env.vault?environment=development' })

console.log(result.parsed) // { HELLO: 'Universe' }
console.log(result.parsed.HELLO) // 'Universe'
console.log(process.env.HELLO) // undefined (as intentioned)

You could still then write the result.parsed object to a secrets.js file.

What do you think?

[1] https://github.com/dotenv-org/examples/blob/master/dotenv-vault-custom-target/index.js

[eladchen]

I can write the file using dotenv with/without using special config.. The idea is is separating the boot process into two phases
the phase where secrets are retrieved, and the phase where the app boots and reads a file with the secrets.

I really think processEnv is a good option, but it only solves half the problem given DOTENV_KEY is still needed.

If you ask me, I think two options should exists, "processEnv", and "spawn" - a callback where the process boot can take place.
When one option exists, the other is ignored.

I would have loved it if the docs outlined this advanced usage and the added security benefits it provides.

[eladchen]

Even if the spawn option seems a bit much, I would still integrate it the way I showed, just because I can & believe its more secured.

Just wanted to share my ideas. 🙃

[motdotla]

@eladchen in this case by spawning that process, those environment variables are technically still available to that process and any third-party module that would have access to that process - they are just in a different place, adding a bit more friction for an attacking third-party. So I think that can be useful in your case.

BUT

I want to clarify that the dotenv module does NOT permanently set environment variables on your machine in case you are under that impression. It sets them only temporarily for the process it is run in. For example, if a process runs and then quits, the values set by dotenv do not persist. A second, or third, or fourth process cannot gain access to them unless they also somehow have access to the same process that dotenv was called in.