Stop Putting Secrets in Plaintext on Local
Discover a secure pattern to manage API keys and credentials locally using a password manager and direnv.
Stock photo for illustration only, not from the actual event
- Stop storing API keys and database passwords as plaintext files on disk
- Store secrets securely inside a dedicated password manager
- Materialize secrets into environment variables only during active shell sessions
- Avoid caching unlock sessions on disk to maintain maximum security
Most local development setups eventually end up with sensitive secrets—such as API keys, cloud credentials, or database passwords—sitting inside a plaintext file on the disk indefinitely. These common credentials often require no verification of identity at the moment of use, simply sitting decrypted and waiting.
A better pattern is to store secrets in a system built specifically for them, like a password manager, and materialize them into the environment only for the duration of a shell session, securely gated behind a master password.
Stock photo for illustration only, not from the actual event
Using a password manager such as Bitwarden ensures that secrets never touch the disk in plaintext. They remain encrypted inside Bitwarden and exist exclusively as environment variables for the lifetime of a shell session within a specific directory, following an explicit unlock action.
To implement this, store the key as a standard login item or secure note in Bitwarden, naming it aws-iam-keys with custom fields for aws_access_key_id and aws_secret_access_key. Additionally, tools like direnv automatically re-execute environment configurations only when the directory changes or the file itself is edited, meaning prompt management is handled out of the box.
Leaving plaintext secrets on local development machines remains one of the most common security oversights. Combining a password manager with directory-scoped environment variables significantly minimizes the attack surface by ensuring secrets live only in memory for active project sessions, making the minor inconvenience of re-entering master passwords well worth the security trade-off.
Best practices for handling local secrets include:
- Audit whether any local secrets remain decrypted and idle on disk
- Combine a password manager with directory-scoped environment loading
- Keep secret material exclusively in memory while working in the project
- Refrain from caching unlock sessions to disk to prevent exposure
Source: Dev.to
Found something wrong in this article? Report an issue with this article
Comments
Leave a Comment