Improve README and website on where secrets are stored

[Cypher1]

I think it's pretty important to be VERY clear and explicit about where secrets are stored and how.

This project's README, tutorials and guides are very keen to focus on how easy using dotenv-vault is, but I think this has lead to understating the work that dotenv-vault does for us.

It would be great to see the docs updated with:

• Where the secrets are stored
• What encryption is used to keep them at rest
• What auth system is used to ensure that only expected groups/roles/systems can access them
• What backup / restore / monitoring there is in place to allow attacks to be discovered.

The tutorial/guide does mention that it's set up with Heroku, but this doesn't seem to be required, so it sounds like there is a 3rd party store for the secrets.

I'd love to learn more

[Cypher1]

Ah, I see. "Below the fold" (i.e. after the first page) https://www.dotenv.org/docs/quickstart talks about an encrypted .env.vault file and an encryption key that gets set in Heroku.

This still doesn't answer my questions about what encryption is used, but does simplify/negate the rest of my concerns.

[motdotla]

We're working on clarifying this. There has been so much that has changed with the introduction of the .env.vault file a few months ago that we're way behind on this.

The short of it for those reading (until we make clearer across all docs) is:

1. If using the local commands your secrets are ONLY stored on your machine. They are encrypted with AES-256 GCM inside your .env.vault file. Your .env.keys (also ONLY on your machine) contain the decryption keys to decrypt those secrets.
2. If using the push/pull etc commands your secrets are additionally stored in an encrypted manner in dotenv.org's vault datastore. The details of this process are at https://dotenv.org/security. They key is separated from from the encrypted value so that an attacker would have to gain access to both databases AND the decryption key.