Maybe it has already been discussed, sorry if it is the case : with mobile apps release, the private key of an user will become mobile too, so more likely to be compromised (lost, stolen, …). Would it worth it prioritizing the differenciation of the keys by device (to be able to disable the one embedded in a compromised device as soon as one realizes its device is lost) ? or at least the way to let a given user change its key (i.e. reencrypt all the passwords with the new one and removing the information encrypted with the previous, compromised one) ?
I now the key is protected by a passphrase, but for me it is sufficient only for letting a short period of time to the user to disable the lost key. Not for just saying “oh, too bad, but let’s forget it”
I also know that I can do it by myself : create another user, share the passwords of the compromised one, delete the former user. But the lambda user does not know… and if it is possible in an error prone manual way, it is possible to do it better programatically
Thanks for reading… and for the amazing work you’ve already done !
NB : for me, password expiry is a must NOT have : password policies must be enforced by the system to be protected (final application, directory, …), not by the user vault (it would rely on the user to change the password, that is a weak control - worse than no control at all because we might think it is done in the system to be protected, whereas it is not). But… regarding the key protecting the secrets of passbolt… it would be nice to have it expiring, with tools shipped along for renewing it (note that it would use the same feature than the one for compromised password I proposed above )