Password management
Last updated
Last updated
We prefer not using shared accounts where possible. We use shared accounts when the plan we can afford to use of a given service does not allow individual accounts for enough users to be practical for our needs.
You should definitely get a dedicated account for any django/flask app we develop.
Use a password manager. We recommend that you use bitwarden or your favourite password manager for managing your own passwords of services you use in your work at OpenUp.
A password that is reused between services, or that is a small variation of a password you use in another service, is not secure.
We owe it to our beneficiaries, clients and reputation as an organisation that can navigate the world of technology to use secure passwords.
Secure passwords are complex randomly-generated text which you can't remember (but use a password manager to look up), or unique complex text like the first letter of each word (or the full words!) of a long sentence. So just use a password manager and use a long phrase for your password in it.
We use BitWarden for shared password management.
We try to follow the principle of least privilege, meaning you should only have access to passwords you actually need. To avoid creating multiple shared accounts on the same service, please add any accounts that relate to your unit's work to the Service Accounts table, and please document when it is the preferred tool for the job in the table above it. Before creating a new account, check if there is an existing account you can get access to and reuse. Duplicate accounts can waste money and effort.
We organise shared passwords according to:
unit - for passwords shared with everyone in that unit, e.g. comms, dev, finance
project - for passwords shared with everyone in the project
Bitwarden can "nest" collections using forward-slashes (/) in the name, and creating a collection for each level in the hierarchy.
Collection permissions are not inherited. Collection nesting is just to visually group related collections.
Giving someone access to the projects collection does not mean they have access to all collections under projects.
When adding items, remember to add them to the relevant collection. The collections can be edited later. An item can be in multiple collections, e.g. the project, as well as the finance collection to give the finance team access to invoices.
Invite new users to the organisation. Once they've accepted, they will have an account and can store passwords for themselves, but they aren't part of the organisation yet.
These users will be listed as accepted in the organisation user list. You will need their bitwarden fingerprint.
They can find their fingerprint on their user profile in BitWarden. It is not secret.
You can accept them into the organisation by confirming their Bitwarden fingerprint after selecting Confirm in the menu next to their name.
Once they are confirmed, add them to any collections they need access to by clicking on their name and checking the relevant collection boxes.
Everyone should have access to
project
unit
and then any specific units and projects they need to access.
Developers will need to deploy credentials via Ansible.
Secure Note type items seem to work best for these kinds of credentials. Use a custom text field for the non-sensitive values, and a hidden field for API keys, passwords and other sensitive values.
We usually organise these credentials in an environment collection under the relevant project collection, and named after the service, e.g. under project/municipal-money we have prod, staging and sandbox matching the environment names used in the ansible inventory. Ansible can then use this name to select the right credential for each environment.
Make sure the item is named consistently across environments so that the same service can be accessed using only an environment name variable in the collection name.
