Q1. What is the problem that you are trying to solve?
Sharing a password with a team member when the permission is “read” is problematic due to the fact that if that team member leaves the team they can copy it and use it.
Q2 - Who is impacted?
This affects only users working as a team
Q3 - Why is it important and/or urgent?
TBD
Q4 - What is your proposed solution? (optional)
So I suggest a new permission “hide password” so that some user can only use a password and not see it.
An admin create a password, share it with a team member, the password is shared but hidden, the team member can use it to login without knowing the actual password.
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)
0voters
admin edit: small edit of the request to match the format. Importance to TBD as generic sentence was used.
From my perspective this feature will not give realistic security benefit. To my knowledge a user cannot just “use” a password without “reading” it. There is no simple mechanism to prevent a user that can use a password to sneak behind the inner working of the application or a given webpage to get access to this information. For example a user could very much use the development tools of their browser to inspect the content of the webpage where the password is used and capture the information when it’s pasted in the page or in transit over the network.
The solution from my perspective is:
Password rotations, e.g. if a user leave the organization somebody need to update all the passwords this person had access to.
As the answer dated from 2017, maybe in the meantime the solution could have been developed.
We have quite a lot of turnover in the team, and that’s why I ask the question again.
The tool corresponds to our needs and this option would have been a plus.
Hello Jeremy, first of all, welcome and thank you for sharing your ideas!
From the point of view of development, everything is possible. But the question is if it really meets your requirements.
You can have a “hide” permission to click and use it in the extension, but as Remy said, the user can use the browser’s developer tools and take the password. Or maybe the ability to copy de password makes it easier to export it. Should it be prohibited too?
The point of this password manager is to make team sharing passwords easier, but in my point of view, this makes it a bit harder and has no real security benefits.
I understand that rotating 400 passwords is a hard job. That is the reason why the company I work for, share the passwords at the moment you need them and not as default. It is easier to rotate just the password you had access and if take out your access, the password is rotated so we do not have to wait until a member is out.
I hope this tip can help you to make a bit easier the rotation job
RBAC feature will be out in the 4.1 and will allow the possibility to block for users the UI feature to preview and copy password, so the only remaining option will be to use the autofill.
For the first version, it will be only for user role, granularity will come later
This is interesting. So the process is to rotate a password after access is revoked for any user. This revoking occurs more often so as to minimize rotations needed at the departure of a user. We don’t really have a best practices page for large teams but this is the kind of thing that should be on it. Thanks @Termindiego25
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)