How to store credentials
Depending on how you manage your accounts, you, your team and the service you run may have credentials or other secrets that you need to store securely.
Examples include login details for:
- GOV.UK Signon
Use the password manager built into your browser in the first instance. This is simpler than setting up an extra account with a third party and avoids some of the potential issues below.
If you can’t do this for some reason, then it’s OK to use a third-party password manager. This could be necessary if your browser has an accessibility issue, or if you work with multiple browsers.
Some of the third-party password managers people use at GDS include:
- LastPass - Approved by Information Assurance and available to install in the GDS Self Service app. However, the free version can only be used on one type of device.
- BitWarden - An open source password manager.
- KeePassXC - An offline password store, which you may want to backup somewhere.
- QtPass - Another offline store, integrated with Git and GPG / pass.
Note that there is a security trade-off involved in using browser extensions to autofill credentials. On the one hand, autofilling credentials can help protect against phishing (for example your password manager will refuse to autofill credentials if
exxample.com attempts to impersonate
example.com). On the other hand, it can be difficult to implement this functionality securely in an extension.
Examples include shared login details for:
- Software repositories e.g. npmjs.org, rubygems.org
- Admin portals e.g. Fastly, DockerHub
There’s no established best practice for storing shared credentials at GDS. Some teams have a “credentials” GitHub repository and use pass to store credentials encrypted with GPG. Make sure you configure the repo as internal or ideally private to help prevent accidental disclosure.
Using GPG in this way isn’t ideal because:
We can’t revoke access to credentials, unless we change them. Anyone who was given access can still decrypt credentials using their local copy of the repo and its commit history.
It creates a high barrier to entry, especially for people less familiar with Unix tooling. We’ve found GPG tools are generally difficult to use and keyservers are unreliable.
Investigate alternatives before adopting GPG-based credential stores for new teams.
- Functional account credentials e.g. API keys
- Sensitive configuration (e.g. IP block lists)
Older (pre-cloud) projects in GDS tend to have a “secrets” repository and use GPG to encrypt files, which are then decrypted during the deployment process. However, using GPG isn’t ideal.