Passbolt design team has published a new blog article about what they have been working on lately which includes some of the new upcoming features of 2022. Check it out!
https://blog.passbolt.com/whats-cooking-for-2022-a2ce136e5c4d
So what do you think? Which one of these should we prioritize first in 2022?
(Mention what it in the discussion below)Safari plugin! 
… but whatever you work on: You rock, just keep on rocking!
What about Escrow? Wasn’t that supposed to be released soon as well?
Escrow (Account Recovery) is indeed the current priority and should be available in a few weeks from now. The list above only includes the improvements and features on which the design team has been working on lately and is not meant to be exhaustive roadmap wise.
Ah, thanks for clearing that up. Really looking forward to Escrow and Password Expiry!
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 !
farfade
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 
)
SAML2 SSO would be nice feature to have
TOTP handling would be neat.
Also I agree with Farfade : password expiration should not occur in the password storage solution
Having password marked as expired, e.g. marked as needed to be changed (but not “automatically deleted” or rotated by passbolt itself), is recommendation from Cure53 audits, so this is something we will implement at some point. This is especially usefull for example when a user is removed from a group, you would want to make sure all the passwords they had access to are rotated, or at least marked as needed to be rotated. To be honest, I’m not following the rationale around this being a security weakness.
Hi @remy !
I agree, there is no problem with security about implementing a " password expiration" feature.
My message was “if you have limited time for passbolt development, please prioritze tools for managing the compromission of (mobile) keys rather than developing a password expiration feature”. 
Thanks for the precision @farfade. OpenPGP key rotation is something we’re planning to deliver with account recovery for the rotation of the “organization recovery key” (aka the one key to rule them all).
The implementation will pave the way for doing it with the end user keys as well.
At the moment the workaround for rotating keys is to delete the user account and recreate it which not ideal but can do the job. In the past user key rotation have not been very popular / high demand, i’m glad it’s being flagged as important.
Those are all very cool features but i would rather have a general usability feature/fix for using folders as not being able to search for passwords that are in folders and their sub folders is making my and my coworkers daily life hard.
@Speatzle “advanced search”, e.g. allowing to search with more parameters, like inside a given folder, was not mentioned in the article but it is something on our radar for 2022. Thanks for your feedback.
https://docs.google.com/document/d/1t4Y1QixcT4Q3I5vCLXcCZli5ezIHCrhmnEx_Bte9HOM/edit?usp=sharing
Hi @remy
i have looked over the Passbolt Advanced Search Specification.
It looks good to me but i have a few suggestions:
It would also be very helpful if the folder/password detail panel on the right would show the entire path in the location field instead of just the parent folder (/Root/org1/folder1).
Hi,
I’m really looking for the ability to enforce the complexity of generated passwords for an organization. It is a recommendation I saw in many audits.
There is already a feature request regarding users’ passphrases, but I think it should be extended to generated passwords/passphrases.
Being able to attach files to credentials is a must have for us.
In our use case it’s essential being able to distribute VPN certificates along with user credentials and at the moment Passbolt does not support it.
Without this we are back to the old days: that is a big spreadsheet for credentials and a folder for secret files.
What is your plan about custom fields?
We are using passbolt pro for store ssh, snmp, san switches, etc. passwords. The current solution for password storing is not the best for custom protocol (not web), custom port, etc.
A new dropdown field for resource type with custom value would be cool too, example:
Resource type: SSH, WEB, SNMP, ILO, MYSQL etc.
@gahkri note that the “what’s cooking” blog post was only about some of the work done in the past few months by the design team, not about the product roadmap.
Good news: custom fields is indeed on the roadmap for 2022. It will allow to store various types of credentials, similarly to the use case you described.
