No. If you do not configure a credential store, Docker saves registry credentials in config.json in base64-encoded form, and Docker's own docs call that less secure than using a store. Base64 is an encoding anyone can reverse. Set credsStore to your platform helper and log in again.
What Docker documents
The docker login reference says that if you use Docker Desktop, credentials are saved to the native keychain of your operating system automatically. If you do not use Docker Desktop, you can configure a credential store in the Docker configuration file, found at $HOME/.docker/config.json on Linux or %USERPROFILE%/.docker/config.json on Windows.
If you do not configure a store, Docker keeps the credentials in config.json in base64-encoded form. The documentation describes this as less secure than a credential store.
Why base64 is not protection
Base64 turns bytes into printable characters so they can travel in text. It uses no key and no secret, so decoding is a single command. Treat a base64 string in a config file exactly as you would treat the password written out in full.
That matters because config.json often ends up in places people do not expect, such as a backed up home directory, a dev container image, a screenshot of a terminal, or a support bundle sent to a vendor.
Set up a credential store
The docs list helpers for several stores: the D-Bus Secret Service, the Apple macOS keychain, Microsoft Windows Credential Manager, and pass. You need the helper program on your PATH. Then you name it in the configuration file. The value is the suffix of the program name, everything after docker-credential-. For the macOS keychain helper, the documented setting is:
{
"credsStore": "osxkeychain"
}
If you were already logged in, the docs say to run docker logout to remove the credentials from the file, then docker login again so they go to the store. By default, Docker looks for the native binary on each platform: osxkeychain on macOS, wincred on Windows, and pass on Linux, with a fall back to secretservice on Linux. If none are present, it stores base64 credentials in the file.
Credential helpers for specific registries
Docker also supports per-registry helpers, configured in a similar way, which let you use different programs for different registries. The default store is not used for registries that have a designated helper. This is useful when one registry issues short-lived tokens through its own tool.
Whatever you choose, log in with an access token rather than an account password where the registry allows it, so you can revoke one token without changing your password.
A quick check
Open your config.json and look for an auths section with an auth value. If you see one and you have no credsStore or helper entry, those credentials are sitting in the file. Fix the store, log out, log in again, and revoke the old token if the file was ever copied.
Where Safeguard fits
Safeguard works on the dependency and code side of your software: SBOM and dependency scanning, reachability analysis and policy gates. It does not store or manage credentials, so keep using your password manager, secrets manager or cloud identity for that. You can run a free scan of a project at gold.safeguard.sh/scan.
Quick check
Is a base64 string a hash?
No. A hash cannot be reversed in practice, while base64 can be decoded by anyone.
Does Docker Desktop avoid this?
The docs say Docker Desktop saves credentials to the operating system keychain automatically.
Do I need to log in again after setting credsStore?
Yes. The docs say to log out and log in again so credentials move from the file to the store.
Sources
Last reviewed: 19 October 2026.
