Most developer tools keep credentials in a config file in your home directory, and several of those files are plain text. The AWS CLI, Terraform, npm, gcloud and others each have one. Knowing the paths, and the safer storage option for each tool, is the fastest way to shrink what a stolen laptop or a malicious package can read.
Why this list matters
A malicious install script or a compromised editor extension runs with your user rights. It does not need to break anything. It only needs to read files you already own. So the useful question is not "is my laptop locked down" but "what is sitting in plain text in my home directory right now".
The map
| Tool | Where the credential lands | Safer option |
|---|---|---|
| AWS CLI | config and credentials files, which AWS documents as plaintext files | IAM Identity Center sign in, which caches a token under ~/.aws/sso/cache and renews short term credentials |
| Docker | config.json, base64 encoded if no credential store is found | A credential store helper such as osxkeychain, wincred or pass |
| Terraform | A credentials block in the CLI config file after terraform login | TF_TOKEN_ environment variables or a credentials_helper |
| GitHub CLI | System credential store by default, plain text file as fallback | Keep the system store working; avoid --insecure-storage |
| Google Cloud ADC | $HOME/.config/gcloud/application_default_credentials.json on Linux and macOS | Short lived user credentials for local work, attached service accounts in production |
| npm | .npmrc files, including $HOME/.npmrc | Registry scoped, narrowly permitted tokens |
Base64 is an encoding, not encryption. Anyone who can read the Docker file can recover what is in it.
Steps to audit your own machine
- List the files above that exist on your machine. A quick
ls -la ~plus a look inside~/.aws,~/.docker,~/.config/gcloudand~/.npmrccovers most of it. - For each one, ask whether it holds a long lived secret or a short lived one. Short lived is better.
- Move long lived secrets into the tool's credential store or helper where one exists.
- Delete credentials for accounts you no longer use. Old tokens are the ones nobody remembers to rotate.
- Revoke, do not just delete, any token you find that should not have been on disk.
What this does not fix
Moving a token into the OS keychain helps against casual file reads, but code running as you can often ask the keychain too. Short lifetimes and narrow scopes are the stronger control, because a stolen token that expires in hours or can only touch one registry is worth far less.
Related reading: AWS CLI sign in or long lived keys, does gh auth login store your token in plain text, is Docker config.json encrypted and Terraform credential options.
Safeguard scans project dependencies and produces SBOMs, which helps you see which packages could run code on a machine like this. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Is the OS keychain always safer than a file?
Usually, yes, against casual reads and backups. It is not a complete defense, because software running as your user may be able to request items from it. Short lifetimes help more.
Do I need to do this on every laptop?
Yes. Credentials are per machine, and old laptops or spare machines tend to hold the oldest tokens.
Sources
- AWS CLI configuration and credential files
- AWS CLI IAM Identity Center setup
- docker login reference
- Terraform CLI configuration file
- gh auth login manual
- Google Cloud Application Default Credentials
- npm npmrc documentation
Last reviewed: 19 October 2026.
