Q1. What is the problem that you are trying to solve?
Organizing passwords in groups is great. In our case we use groups to share passwords for our client projects. Any password, things like demo logins up to credentials used in production. The downside of sharing passwords with a group is, that I am not able to use further rules who is able to see which passwords. It’s all-or-nothing. Sure, I could introduce another group for more confidential passwords but that would ruin our naming schemes of the groups (which are the same in our org all over the place) as well as make navigating in Passbolt more complex as the users would need to check both groups for the password they are looking for.
Q2 - Who is impacted?
Q3 - Why is it important and/or urgent?
Q4 - What is your proposed solution? (optional)
I could imaging marking user accounts as being able to view “confidential” password entries and then also let the user mark password entries as “confidential”. This is kind of similar to a feature GitLab offers where they allow to mark issues as confidential.
Q5. Community support
People can vote for this idea to show traction:
Must have: this is critical for me to have this
Should have: this is important for me to have this
Could have: this could be nice to have
Won’t have: we should not schedule this (explain why)
Passwords are “confidential” by their very nature and those that are not are a rare exception.
It sounds to me like you are sharing passwords with groups that include people who should not have access to those passwords. That is an error in your usage of the group feature, and should not be solved by adding another layer of complexity to the software.
In a password manager, a group is by its very definition “the group that can access the passwords shared with it”. Using any other definition of “group” (i.e. existing structures of an organisation unrelated to passwords) will create the issues you are currently facing.
But let’s toy with the idea for a moment:
From a strict security standpoint, when creating passwords the default value should be “confidential” and when creating users the default value should be “not allowed to see confidential entries”. Both can then be changed as needed.
Now the first contact of new users will often be “i created a password, but i am not allowed to see it?!”.
So we need an exception: “does not apply to password owners”.
What if a group is the owner of a password? What if that group is arbitrary and not only includes people which should have ownership, but also other people? The answer should not be “lets create a trusted flag” but must be “don’t give that group ownership”.
And in the same way for you the answer must be: do not give a group of people that should not have access to a confidential password access to a confidential password.
It sounds to me like you are sharing passwords with groups that include people who should not have access to those passwords. That is an error in your usage of the group feature, and should not be solved by adding another layer of complexity to the software.
For us groups are a collection of similar things, e.g in our case all passwords that belong to the same project. That should not necessarily mean everybody that is part of the group has the same rights to see or modify the entries (e.g. a student working for us should be able to access the credentials of a demo account of the application but for sure not get in contact with the different credentials of the production environment). Sure, technically the easy fix is to create just another group, but in practice this makes the whole organisation of passwords more complex for us due to the following reasons:
having a 3 digit amount of groups in our other applications makes maintaining them in Passbolt quite complex. Doubling the amount of groups just for the sake of managing the password visibility will complicate maintenance of groups and access rights even more. Currently, we don’t have all groups in Passbolt, but we are working on it.
The current way Passbolt deals with groups too limited. Not having sub-groups is a problem, the way groups are currently displayed is problematic with a certain number of groups.
since we use a very strict naming scheme for groups across all our applications, this would complicate setting up groups everywhere else due to possible naming clashes.
In a password manager, a group is by its very definition “the group that can access the passwords shared with it”. Using any other definition of “group” (i.e. existing structures of an organisation unrelated to passwords) will create the issues you are currently facing.
Where have you gotten this definition from? Is this the definition used by the Passbolt team or from some other source? Assuming we are doing things wrong and grouping password that are not related to each other is a bold statement. “Related” can have many different meanings.
All I am asking for is an additional way of managing visibility & permissions because grouping passwords does not feel enough. And just adding more groups to solve the issue sounds like the wrong approach to me.
Must have: this is critical for me to have this
Should have: this is important for me to have this
Could have: this could be nice to have
Won’t have: we should not schedule this (explain why)