Q1. What is the problem that you are trying to solve?
Suppose a large number of devices (e.g. switches) share the same password. When the time comes to change the password, we log into them all and change them, and update Passbolt with the new password.
However 6 months later, we discover some device running in a forgotten closet, or which was powered off during the password change, still using the old password. We cannot remember the old one.
If we are lucky, we may might have a backup of the database from 6 months ago. However it is painful to restore and use such a backup.
Q2 - Who is impacted?
Users who follow good practice in rotating passwords periodically.
Q3 - Why is it important and/or urgent?
Passbolt makes it easy for a person with “can update” or “owner” access to change the password; but as soon as this happens the old version is permanently lost (except for SQL-level backups)
We could try to ask people to create separate named resources for each generation of password (e.g. “root-1”, “root-2”, “root-3” etc), but this is not enforceable since the UI encourages passwords to be updated in place.
Q4 - What is your proposed solution? (optional)
Make passwords immutable - at least the “secrets” part (I’m not too worried about the description and URI being updated)
Implementation might include:
- Add a
current_versioncolumn to the
- Add a
versioncolumn to the
- Use the combination of (
version) to look up secrets
- On changing a secret, increment the
current versionfor the resource and write out new secrets rather than modifying old ones
- In the UI, have some way to browse previous versions
Consideration: when adding/removing users to password sharing, this would need to re-encrypt previous versions as well; this will become slower the more historical versions there are. Also the database will grow with historical versions.
So an alternative approach would be to encrypted all passwords with an archive public key, and dump them in an archive table or directory on every change. Then only a sysadmin with access to the archive key would be able to retrieve them.
Q5. Community support
People can vote for this idea to show traction:
- Must have: this is critical for me to have this
- Should have: this is important for me to have this
- Could have: this could be nice to have
- Won’t have: we should not schedule this (explain why)