All articles

Introducing the upcoming “Account Recovery” functionality

9 min. read

Passbolt team

Passbolt team

8 September, 2021

Sorry, you’re on your own
Are you ready to get on with it? Grab a drink, put on your security researcher and designer hats and let’s dive in.

Is it the Escrow feature?

What problems are we trying to solve?

Who’s impacted?

What are the current workarounds?

Manual sharing policy

Manual backup policy

What are the options?

Option 1. User private key backup using an organization-wide key

  • It provides a user-friendly way to recover an account. The administrator/recovery contacts are involved to validate the request and support the user in the process. Since the process is initiated through self-service, it’s straightforward for the user and reduces overhead for the administrators.
  • It’s simple to implement as an incremental feature. This would only require a change in the initial account setup and recovery process and some new settings screen. It’s also backwards compatible for other clients (which do not support initial account setup at the moment).
One key to rule them all
  • If this setting is enabled there is no real safe way to store “personal passwords”, as everything is technically visible by who has access to the organization recovery key.
  • It allows impersonation of end-users by administrators, for example an administrator who has access to both the organization recovery key and the user mailbox could perform an account recovery, sign in as the user and perform actions in their name.
  • It increases brute-force attack risks. An attacker with server access, would be in a position to try to brute force the key encryption directly (instead of having to brute force the passwords individually).
  • It discourages the reuse of users’ keys in different applications. For example, if the same key was to be reused to send encrypted emails, an administrator with access to the organization recovery key would be able to read their emails. *In some cases this might be desired (for example in a regulated environment). However, in other cases it would mean making sure the users do not reuse their keys elsewhere.

Option 1bis. Adding Shamir Secret Sharing for collegial recovery

Option 2. Resource backup using organization-wide key

  • It doesn’t prevent reusing the users’ keys in different applications. It offers a more granular control, at the resource level, of what will be in backup.
  • It can be built reusing the existing permission system. The option would be based on the current “share” capabilities that users are already familiar with. For example the “escrow agent” would be added as an additional share recipient, and such a user, depending on the policies, would be added by default and users may or may not be allowed to remove it from the permission list.
  • It’s more complex to implement. It would require a major API version change, as it would demand a change of behavior on the create endpoint. For example if we want to force clients to share credentials with the service account during the creation of an item (e.g. mandatory backup policy).
  • All clients will need to support the functionality, creating a major breaking change in the entire ecosystem (custom scripts may stop working, mobile, cli, desktop apps, all will need to implement something).
  • Depending on the settings, users may not be able to recover everything, still creating frustration. Depending on the default policies users may not be able to recover everything and fail to recover personal passwords for example. Some users could work around these policies to make sure some secrets are not included in the escrow even though they should (for example not sharing with the right groups, without other users noticing).
  • It may be harder to understand for end users. Complex policies will lead to human errors such as placing things in escrow even though they shouldn’t.
  • Some parts of the process will be more resource intensive. When a user loses their keys, the administrator will be needed, with the help of the organization recovery key, to decrypt and re-encrypt all records using the new user key. In other words, performance issues are to be expected during recovery when rotating keys for the user. Moreover, it would require a separate improvement to allow sending a large set of secrets (cf. currently a bottleneck occurs when adding a user to a group with a lot of passwords).

Selected approach

Continue reading

What will the “Account Recovery” functionality look like?

6 min. read

What will the “Account Recovery” functionality look like?

A walk through of escrow, or the Account Recovery feature for passbolt. Find out how it’ll look and what you can expect.

Passbolt team

Passbolt team

28 September, 2021

Passbolt security audit 2021 - Part 2

2 min. read

Passbolt security audit 2021 - Part 2

Part II — Firefox and Chrome web extensions

Passbolt team

Passbolt team

1 June, 2021

Flag of European UnionMade in Europe. Privacy by default.