As a company owner, I can retrieve any secret stored in the company passbolt instance

Feature requests Done!
1

Q1. What is the problem that you are trying to solve?
If an employee leaves the company, and has stored company secrets in passbolt without sharing them, then currently those secrets are lost forever.

Being able to retrieve those secrets may be critical for business continuity.

A related common problem is when a user loses access to their own private key (e.g. reinstalls their PC without having taken a backup of the private key), and has unshared secrets in passbolt. There are other possible solutions, but having company access to the secrets covers this use case too.

Q2 - Who is impacted?
Any business which uses passbolt to store company-owned information (e.g. device access passwords), where the passwords are created and entered by end users themselves.

The business is reliant on the user remembering to share the passwords with the appropriate other users or groups. This is an extra step which can easily be forgotten until too late.

Q3 - Why is it important and/or urgent?
This scenario of password loss has happened. It results in a real mess which needs cleaning up, and it means that passbolt itself has become a business continuity risk.

Our current workaround is doing periodic direct SQL queries to report on unshared passwords, but this is awkward and often goes for a long time without being done.

Q4 - What is your proposed solution? (optional)
I would like all passwords to be shared by default on creation with a configured “escrow user” (or group) - a regular passbolt account or group - as owner. Removing sharing with this account would be forbidden.

There is no special escrow encryption required. It would just use the normal sharing mechanism, so all secrets would be encrypted with the escrow user(s) PGP keys.

The UI would show explicitly that the password is being shared with this user or group, and I believe this removes any privacy concerns - e.g. if someone thinks of entering their personal bank account details, it would be very clear that they are sharing it with the company. A warning banner could also be added.

The escrow user/group will be able to see (and share) all stored secrets in this passbolt instance, but not anybody’s private key.

User stories:

  • As company owner, I install a company instance of passbolt
    • I create “System escrow user” and store the private key and passphrase in the company safe
    • I configure passbolt to require sharing of all passwords with this user, e.g. via config file or GUI
    • I tell my staff to enter all company secrets in passbolt, but no personal secrets
  • As end user, I create a new password
    • Sharing with “System escrow user” (as owner) is pre-configured and cannot be removed
    • Banner warns me that all passwords stored in this system may be retrieved by the company
  • As company owner, once an employee has left:
    • I find all passwords owned by that employee and not shared. If there are any:
      • I retrieve escrow user credentials from the company safe
      • I share the orphaned passwords with appropriate users or groups
    • I delete the employee
  • Alternative version of user story is to have “System Escrow Group” which in turn contains one or more system superusers. Any of those superusers can recover any password; there is then no need for a special escrow user.

It’s also worth considering how and if this relates to passbolt’s concept of “admin role”. Rather than configuring an escrow user/group, it might be worth having another user role (e.g. normal, admin, escrow-admin)

Related issues

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

2

Voted for “should not”. Explanation: conflicting use case “personalised account passwords”:

We suggest to our workforce to store passwords for personalised accounts, which contain a clause “you don’t share access to this account (with anyone)”. Reason: ease of use - only one password manager.
Creating a single super account that can open all passwords breaks that.

This feature would make Passbolt unusable as a generic password manager and make it necessary to have two systems: one where you can store personalised accounts you should not share, and passbolt, where you store passwords that can be shared.

3

I voted I would not use because: I don’t think this is the right way to address the need. Requiring sharing all passwords with the company is better handled, in my opinion, with the company managing all passwords and issuing them to users via not issuing them at all (and using a single sign on instead). Requiring sharing in the proposed scenario eliminates employee control, obviously. My rule of thumb would be: control over the password should be exercised by the one sharing it. They should be responsible to change it when needed, etc. They should be able to revoke when needed.

A good policy as a company is to prohibit creating of external accounts for the purpose of conducting business without first gaining approval and permissions from the company to do so which gives the company a chance to establish supervision, if needed.

1 Like
4

The account recovery feature was released in beta with v3.6 of Passbolt Pro Edition. It allows to recover user accounts when they leave if they have shared their key with the organization recovery key and if you have access to the email address mailbox.

Cheers,