[PB-33599] As a user I can retrieve previous versions of a password

Feature requests
,
1

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
7

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.

8

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

9

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.

1 Like
10

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?

11

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.

12

Is there any definition of if this is available? As above, i don’t want to lose the password history on the system for risk of needing to reference it at a later date.

1 Like
13

Hi @tota8784 A current default feature is the password is sent by email notification upon creation. That email is essentially a form of personal backup in case of no access to the server as it can be decrypted with your private key that you also store for safekeeping. It is also a de facto backup of old passwords. Just don’t delete your emails, of course.

14

Hi @garrett. Okay, you’re right, the password are sent in email. But it’s hard to keep something like 200 password updated at least once every year (most of the time each 3 months) in our mails …

Also sometimes, we “just” need the last password for a couple of minutes (e.g : when you’re changing it and the site won’t take somes specials chars).

1 Like
15

@Luclis I agree, the emailed backup is only that. A last resort, in my opinion. However, the previous concern was whether there was any history at all, if a history in the system was no longer in place.

16

Any change to this? I am encountering issues when attempting to decrypt PGP messages sent from the self hosted solution using my downloaded key from the server. It would be best if I could see at least what the password was prior to the last change.

17

I feel like this is one of the most underrated features. True, you may not need it 99% of the time, but that 1% of times when you do need it, it might be an essential thing. I’ll rather take option to have 10x the size of each entry holding last 10 changes than spent my time trying to recover account or deal with non-existant customer support on some services.

1 Like
18

This is actually a reason why I’m not changing to passbolt from 1password (in my company) and keypass (at home).

I’m actually losing information that can be important or useful. Several times I needed to use older password that already been updated in the vault. And the cost of losing the data could be significant.

19

There is an option if you keep your emails and enable the encrypted secret:

image
image712Ă—276 17.2 KB

Inside the /app/administration/email-notification
You will receive the content of the encrypted secret at the creation and each update.
So once done you can take that part and decrypt it locally with gpg command line.
Not the most user friendly I agree but totally doable until it is implemented

1 Like
20

Related: As a user I would like to use Passbolt to manually encrypt and decrypt

(Since most users who aren’t admins don’t visit the command line as often… A field to drop an old password into would be handy.)

21

Come on, Garrett! I know you like the command line. I bet you start your car with it. :stuck_out_tongue:

22

Yes, the idea will be to store the previous versions of the password in the JSON of the encrypted secret.
This will be part of the big work in progress to have different content types in the application

23

This is a tiny part from above that stands out as being different from a history feature. This is a point of friction related to “steps to change passwords”. If I can’t find another request like it I think I will break it out as a new one. @max Do we have anything in the works at the moment related to it?

24

not more of what I said here: As a user I can retrieve previous versions of a password - #22 by max

25

You can start cars with it? That would be great for my team on the road!

I just want to know if the command line is toll free, and will we have our own number? Will anyone pick up when I call? How will they know who I am?

These are important considerations for my fleet before I tell them about the passbolt command line.
:nerd_face:

1 Like