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.
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.
Moderation edit by @_jc: there is no need to hard delete users in database. @remyexplained this some posts below 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.
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 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 . 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.
@oidc_user it is on the roadmap but not high on the priority list at the moment. Currently we’re working on Google SSO, TOTP support, passbolt desktop app, password expiry, extension manifest v3, ldap refactoring. We’ll try to finish these first before starting something else