← back to docs

Dotenv Vault

The Dotenv Vault holds your secrets in a secure and sophisticated way.

We've been trusted with securing hundreds of billions of secrets through our dotenv node module, and we are bringing the same level of trust to Dotenv Vault.

How does it work?

Step 1
Securely Send to Dotenv

When the user types dotenv-vault push their .env file is encrypted and sent securely over SSL to Dotenv's in-memory servers.

This encrypted payload is decrypted and held in memory briefly in order to complete the next steps. Afterward, the memory is flushed so you can rest assured the decrypted version is never peristed anywhere on Dotenv systems.

Step 2
Parse Secret Parts

In-memory, the contents of the .env file are parsed to their prospective secrets (line by line) and secret parts (the KEY and VALUE separated by the = equal sign).

This division of secret parts (KEY and VALUE) is by design. They will be stored in separate databases for added security. This way if an attacker somehow gained access to one database they would not be able to make sense of the data - having only half of the puzzle.

Step 3
Encrypt Secret Parts

The KEY is encrypted. The VALUE is encrypted.

They are encrypted with different master encryption keys. This way if an attacker somehow gained access to the VALUE decryption key they would find the data useless. They would not know if the secret belonged to Twilio or to AWS.

Encryption uses the AES-GCM algorithm. It is:

Additionally, all master encryption keys are rotated on an unpublished schedule, further adding to the level of security.

Step 4
Tokenize Secret Value Part

The encrypted VALUE is sent to Dotenv Vault for safe storage. A token is returned as an identifier. The token is used in the next step for mapping the KEY to the VALUE for later secure-read operations.

Multiple security measures go into the Vault. They include but are not limited to:

  • Separate datastore from the application database
  • Not accessible via the internet and all external connections are prevented
  • Encrypted clients are required and these clients have to go through the application - which has its own additional layers of encryption
  • There are stricter TLS requirements for connecting to the Vault. TLS 1.0 cannot be used to connect.
  • The secrets stored in the Vault are not just encrypted at the datastore level. They are also encrypted at each datastore entry as you saw in the prior step(s).
Step 5
Store Key Part with Token

Lastly, the encrypted KEY and token (representing the encrypted VALUE) are stored together in the application database. A success message is returned to the user.


Vault Security Specifications

  • The Vault is a separate datastore from the application database. This way if an attacker gains access to the application database they do not gain access to the vault datastore.
  • The Vault datastore is not accessible via the internet and all external connections are prevented. This way an attacker can not remotely access the Vault datastore.
  • Encrypted clients are required and these clients have to go through the application - which has its own layers of encryption.
  • There are stricter TLS requirements for connecting to the Vault datastore. TLS 1.0 cannot be used to connect.
  • The secrets stored in the Vault are not just encrypted at the datastore level. They are also encrypted at each value. This way even if an attacker gains access to the datastore they could not make sense of the encrypted values.
  • The VAULT does NOT store the key of the secret. It ONLY stores the value. The key is stored in the application database and a shared pointer (in both datastores) allows them to be identified as a pair. This way an attacker would have to gain access to both the application database and the Vault datastore to make sense of the values.
  • The encryption key(s) used to encrypt the secret values are rotated on an unpublished schedule. This way an attacker might gain access to an old encryption key but not the most recent - foiling their ability to decrypt the secret values.
  • Encryption uses AES-GCM encryption. It is a well-studied, NIST recommended, and IEFT standard algorithim.

As you can see, we go to great lengths to make sure your secrets are safe. Afterall, we keep our secrets here as well.

← read more docs

admins only owners only