What do you think of the upcoming “Account Recovery” (Escrow) functionality specifications?

Hello,

As you may have noticed we just published a blog post with regards to some upcoming account recovery functionality that will be first available in the Pro and Cloud versions.

We are also running a short survey if you would like to share your feedback:

Of course you can also discuss it here!

3 Likes

The Shamir option looks awsome for an organization. But before that is done a account reset feature would be good and easy. This reset would wipe the account and all its passwords and then recreate the account using the same email. Currently this has to be done manually via sql to be able to recreate a account with the same email (because the ui only soft deletes the user, its resources, secrets and permissions). This will also be usefull if the user opted out of the account recovery when its here.

1 Like

The regular recovery procedure will be carried out using “recovery contacts”. In this setup, when a user initiates a recovery procedure, the recovery contacts will need to collaborate (asynchronously) to reach the required threshold to rebuild the private key passphrase (passphrase that is needed to decrypt the user secret key backup).

In practice the user key passphrase would be split into multiple secrets using a shamir secret sharing scheme, and these secrets will be encrypted using the multiple recovery contacts public keys.

Can you explain more the process of Shamir validation? Specifically, how is the passphrase being derived - is it based on the polynomial?

Also, if it’s an asynchronous process, how are the passphrase “pieces” being stored (in decrypted form?) while awaiting for any remaining pieces to be decrypted by the appointed recovery contacts? And are the recovery contacts provided truly only a piece of the passphrase or also additional data for curve validation?

Nice writeup! Exciting to see some activity on this.

This is exactly the painful process I have had to go through every time a user forgot their passphrase.

Just FYI, you always have to soft-delete the account first, otherwise their ID will cause issues when interacting with the group they were in.

1 Like

You don’t have to soft delete first, if you hard delete a user and then run the cleanup cli command, it will fix all relationships.

Oh, I did not know that. Thanks!

It still is a shame that for something as “trivial” as this you have to manually delete rows in the database.

This is not true to my knowledge. You should be able to delete a user in passbolt using the UI and then recreate another user with the same email. If this doesn’t work or there are some bugs introduced by it let us know, as this should work.

You shouldn’t have to delete anything in SQL for this to work :slight_smile: . If you have to it’s a bug.

I see how i got the impression that it has to be done manually, all work related Passbolt instances (where users actually lost their accounts) i look after use AD Sync, and when you delete a User via the UI then the AD Sync tells you that the account Cannot be Created because it was Previously deleted. So the conclusion was that that you have to use SQL to hard delete the user for the AD Sync to recreate it, i never thought that the UI would be different from the AD Sync…

This is our exact setup, we use LDAP as well and since the new account would be added manually and not through LDAP, account deactivation when the underlying AD account is deactivated would not work (at least AFAIK).

This method of reset is also not ideal, because it probably messes up Activity Log - since you remove the user from the DB and the new account receives a new ID, the already logged activity for the old user will be:
A) Deleted from the DB, if the primary key of the user (ID) is a foreign key and the table is set to cascade on it¨s removal. The result would then be completely missing activity log for the old user.
B) Kept in the DB, but since the user ID is unknown to the database, it will be useless since that user no longer exists.

This also makes the new feature of Account Recovery much more needed.

Actually passbolt ldap sync is “smart” enough to recreate the link with LDAP when you manually add it back. Basically it goes like this:

  • User is created in LDAP
  • User is imported in passbolt using sync’
  • User is deleted in passbolt / User is still present in LDAP
  • User is not added back during passbolt ldap sync
  • User is added back manually in passbolt
  • Passbolt LDAP sync recreates back the link in the database (eg. remove a “not in sync” flag)
  • User is deleted in LDAP manually
  • User is deleted in passbolt using sync
1 Like

Oh, that is great news!

Since I haven’t found this in the documentation, I didn’t think it worked this way. Would it be possible to add this to the FAQ section, maybe?

Thanks!