As a user I can retrieve previous versions of a password

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_version column to the resources table
  • Add a version column to the secrets table
  • Use the combination of (resource_id, version) to look up secrets
  • On changing a secret, increment the current version for 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:

  • :ok_woman: Must have: this is critical for me to have this
  • :raising_hand_woman: Should have: this is important for me to have this
  • :tipping_hand_woman: Could have: this could be nice to have
  • :no_good_woman: Won’t have: we should not schedule this (explain why)

0 voters

1 Like

Oddly, I can no longer see the discussion which took place under this topic.

However the summary is: passbolt used to keep previous versions in the secrets table, but this functionality was removed for simplicity, and it’s intended to stay that way for v2.

@candlerb yes I removed the conversation and sent you a message :). That is keep your request clean for new people.

Why was it removed? Can i get a status update on this? We currently use keepass and keepass stores historical data of passwords should this scenario happen.

Will the “Audit logs (Pro)” feature have historical data for passwords? or will it just tell me who changed which password not what the password was?

Hello @psampollo_tti

Unlike v1, v2 does not hold the history of secrets anymore. It was removed as it was not used, as well as in a effort to speed things up.

It is envisioned however that the audit log feature will keep a trail of old passwords in the secret_history table in the the database. This most likely won’t be available in the coming weeks. At the moment it will only tell you who changed the password and when.