Account Recovery Issues - Wish To Use Decrypted Keys

Hello there,
I am currently using passbolt through a docker deployment, with image passbolt/passbolt:3.4.0-ce.

A user of our Passbolt system was setting up on a new machine and going through the account recovery process. They had been good and followed the advice of keeping their downloaded key file on their computer from when they originally set up the account. We uploaded that OpenPGP key, and they had to enter their passphrase, which they had inevitably forgotten. We eventually gave up, and created them a new account.

This time, I wanted to be sure that it would not happen again, and went to the effort of checking if the newly downloaded recovery key had a passphrase (which it does), and then removing the passphrase and exporting the passphrase-less key. We then deliberately went through the account recovery phase again, to check that we could use this passphrase-less key in future, should they were to forget their passphrase again. Unfortunately, the website always asks for a passphrase, even though the key doesn’t need it, and entering nothing into the passphrase field does not work.

I guess that technically, should this ever happen again, I could take the passphrase-less key, apply a new passphrase to it with the user, and upload that key to the system to recover the account (I’m guessing this should work and have not tried it), but this seems like an extra hassle that one should not have to go through with. It would be great if the system could notice that the key file does not have a passphrase, and in such a scenario, use the key and ask the user to set a passphrase in the system. I swear that this used to be the behaviour on a really old version of Passbolt that I used in the past.

Am I missing something and this should have worked? If the system cannot tell that the key does not need a passphrase, I would be happy with a solution whereby I would need to check a checkbox to tell the system that the key does not take a passphrase, and that we would need to set a new one.

Hello @programster,

Yes, this is somewhat of a common issue even at my company - people just forget their passphrase, which means they cannot recover the account.

I don’t think saving the recovery kits without password protection is a good way to go about solving this.
The solution to this is already in making - Escrow (Account Recovery). With that implemented, the recovery kits are going to be stored on the server and encrypted by the organization’s public key.

So for now, I’d just recommend waiting for Escrow, as your problem (without manually encrypting the keys yourself with a new key-pair) does not have an easy solution yet.

I am “sort of” doing the same thing, by just using a local encrypted zip (aes-256) with the password I know, for restoring the keys. The point that I’m trying to make is that I need to keep these user-keys passphrase-less to get around the issue of users forgetting their passphrases. Right now, I have to go to the effort of importing the file into gpg, running passwd, to remove the passphrase (requiring me to get it from the user, rather than the user giving me the passphrase-less key), and then storing them in the encrypted zip. I then have to retrospectively go through the process in reverse in order to add a passphrase if I wish to recover.

It would be a lot simpler to me if the system could be configured to work with passphrase-less keys. E.g. when the user is given the backup key, and when the key is imported into the system again. By all means put a warning in there, and have this not be the default setting, but I would prefer to rely on my capability to keep the keys safe as an administrator, rather than relying on users remembering passwords/passphrases.

I think I found the escrow post. That would work nicely, as long as the admin key is encrypting a passphrase-less version of the user key, rather than re-encrypting an already encrypted key. The latter would not resolve users forgetting their passphrases. This has already been pointed out in the comments.