Hidden secrets become visible for users with "Hide Passwords" ACL option enabled - Apply "Hide Passwords" ACL to Password History view

cksapp commented 3 years ago

Subject of the issue

Hidden secrets can become visible to users with "Hide Passwords" access control option enabled.

Steps to reproduce

Create an organization.
Invite a user to this organization with role "User" and access control to a selected collection with "Hide Passwords" checkbox on.
Using the admin user, create a new password entry within the organization, inside of the collection that we approved to the invited user. Something basic, like an username, a password, and a hidden custom field. Save.
Log in with the newly invited user account, and inspect the entry in the collection. Secrets, such as the password and the hidden custom field, are unable to be viewed.
With this newly invited user account, delete the custom field in that entry and save.
Using the user account, check that entry again. At the bottom of the modal box, there should be a clickable "1" next to Password History. Click and it will reveal the hidden value of the custom field, which was not viewable prior to its deletion.

Expected behavior

As the organization specified that secrets should be hidden from this specific user, that user should not be able to directly view those secrets in any way. Therefore, when clicking "Password History" at the bottom of the entry, the secret value should not be shown if the user access control does not allow so. As a current workaround, those users may also be specified with "Read Only" ACL enabled to prevent from editing entries.

Actual Result

The user is able to retrieve secrets from the organization against ACL rules.

Environment

Operating system: [Windows 10 Version 21H1 OS Build 19043.1110]
Browser: [Microsoft Edge Version 92.0.902.55 (Official build) (64-bit) And tested Google Chrome Version 92.0.4515.107 (Official Build) (64-bit)]
Build Version: [Version 2.21.1]

I had not seen this issue posted in either Bitwarden community forums, nor in open or resolved GitHub issues. Wanted to repost this to have seen by the awesome devs. Credit to original user to discover this concern

cksapp commented 3 years ago

"Password History" also shows the Hidden Fields data when hidden field name is changed by user as well as when Hidden Field entry is deleted.

bitwarden-bot commented 2 years ago

Hi @cksapp, We're cleaning up our repositories in preparation for a major reorganization. Issues from last year will be marked as stale and closed after two weeks. If you still need help, comment to let us know and we'll look into it. Thanks!

cksapp commented 2 years ago

Hello @bitwarden-bot and staff,

I have not seen any activity regarding this issue. Checking recently this does appear to still be a concern as the detailed steps above were tested and appears to still be replicable.

Currently the ACL allows for the assigned user to have edit capabilities to the entry, as expected as Read- Only is not selected; but does stipulate the Hide Passwords option is enabled. Perhaps a better edit for this would be that the Password History section of an entry should be considered as a hidden secret as well, and not able to be viewed by a user with the Hide Passwords option enabled. Similar to how both the Password section and a Hidden custom field become unable to be toggled by a user with these permissions. This should also apply to the Password History section and be unable to be viewed.

cksapp commented 1 year ago

As an aside while I was revisiting this, I am not entirely sure that the web label is strictly correct. Unless this is configured separately within each client. In which case we should probably add tags for the browser-extension, desktop (I haven't yet had a chance to test this on CLI), as well as track in mobile.

Otherwise I believe this may possibly be a configuration on the server side, and may instead be best suited there to apply Hide Passwords policy to the Password history view.

bitwarden / clients