Allow for alternate storing of secret key (and encrypted env?)

[baohx2000]

Just some thoughts for doing this:

• Have a KeyStorage interface with getSecretKey() method
• Let the user pass their KeyStorage object in the initialization

Going this route, you might also have an EnvStorage interface to allow for alternate ways of storing the encrypted environment variables. Implementing this might help keep away from dreaded major version releases.

[johnathanmiller]

A KeyStorage is a great suggestion. I'm also interested in entertaining your comment on Medium. From my understanding you're saying, instead of using a key file, to generate a key into a private cache whenever the server starts?

[baohx2000]

Just for reference, my comment from https://medium.com/@baohx2000/an-option-for-being-more-secure-might-be-to-not-actually-store-the-secret-key-as-a-file-but-only-b451efc8f776

An option for being more secure might be to not actually store the secret key as a file, but only output it once upon encrypting the environment (this could be a production-build-time process), and on the production system, have the key stored/injected into apc or some other relatively private cache. That way if a hacker gets your files, it doesn’t matter (well, it does in that you definitely have problems at that point, but at least they wouldn’t have your secrets).

The process would be something like:

1. Prepare env file for encryption
2. Feed env file to encrypt command
3. Encrypt saves env.enc and key as expected

At this point, the encrypted enc is sent on to whatever build as expected. FYI, I'm thinking along the lines of a docker build process. As the container spins up, it could fetch the key from a known service only accessible on the internal network (there are quite a few secrets services that could be used), and injects it into APC or some other in-memory cache. This keeps the key out of easy-to-find places like config files or $ENV. This could also include fetching the encrypted env itself to be even more obfuscated...so even if someone gets the container image file, they still wouldn't have the secrets, even in encrypted format.

TLDR - The article comment was more a suggestion allowing for a more secure build process than this project itself, but it would require the abstractions requested in order to make it happen.

[baohx2000]

Another idea would be to use https://github.com/paragonie/hidden-string to store the unencrypted values. This really helps keep them out of things like stack traces or other logs/errors.