tka85 / dotenvenc

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Encrypt Values Only

cawoodm opened this issue · comments

We would like a solution which encrypts only the values, not the entire .env file.

.env v1

foo=bar
baz=1

env.enc v1

foo=af7a7a7f...
baz=98e7f...

Reasoning: it may be useful to do diffs on .env files and see at least which key was changed. Currently, changing one key means a completely unrecognisable new encrypted file.

.env v2

foo=bar
baz=2

env.enc v2

foo=af7a7a7f...
baz=1e62nee..

Here we can see in a difftool that baz was changed.

Would you be prepared to do this or would you prefer we fork your project?

That's an interesting idea.

So, to maintain backwards compatibility, running with -e would still generate as per usual the .env.enc file with all content encrypted. But now it would additionally generate a .env.enc.readable that would have only the values encrypted, like:

foo=af7a7a7f...
baz=1e62nee..

But there is a catch. This assumes that the encrypted form of a string is always the same as long as we use the same password. But that is not the case with encryption. Encryption starts by initializing a vector with a call const ivBuff = crypto.randomBytes(IV_LENGTH). This means consecutive calls with the same password give completely different encrypted output.

What I could do, is generate an HMAC digest for each of the values. That would guarantee that each time you run it with the same password, it would only change the digest of the values that have changed and you'd pick that in your git diff.

You shouldn't add the .env.enc.readable in your .gitignore so that you'd pick up the changes, but on the other hand you should be careful not to commit it either. Even though HMAC is a cryptographic hash function which is designed to be difficult to reverse, publishing the digest could potentially expose you to certain types of attacks. For instance, if an attacker knows the mechanism you used to generate the HMAC, they might attempt a brute force or dictionary attack to deduce the original secret. It's always best to keep both your secrets and their digests private.

Sound good enough to you?

This has been implemented as v5.2.0.