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.
Personal credentials belong only to you. They uniquely identify you and grant access to your GitHub, AWS, and GOV.UK Signon accounts.
If possible, use the password manager built into your browser. This is simpler than setting up an extra account with a third party and avoids the potential issues below.
If you are unable to use your browser’s password manager then you should use a third-party password manager. This could be necessary if your browser has an accessibility issue, or if you work with multiple browsers.
Third-party password managers used by people 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.
There is a security trade-off involved in using browser extensions to autofill credentials.
Auto-filling credentials can protect against phishing attacks. Your password manager will refuse to autofill credentials for the wrong site, such as
exxample.com attempting to impersonate
example.com. However, it can be difficult to implement this functionality securely in an extension.
Credentials sometimes need to be shared across a team or programme. Software repositories (NPM, RubyGems, Maven Central) and admin portals (Fastly, DockerHub) will often have shared credentials.
Investigate alternatives before adopting GPG-based credential stores for new teams.
We cannot revoke access to GPG-based credentials unless we change them. Anyone with access can still decrypt credentials using their local copy of the repo and its commit history.
It creates a high barrier to entry as GPG tools are generally difficult to use and key-servers are unreliable.
Deployed services sometimes need sensitive configuration such as API keys and IP block lists.
Older projects in GDS might have a “secrets” repository and use GPG to encrypt files, which are then decrypted during the deployment process. This approach should not be used unless there is no better option.