Hello,
i suppose that when a user exports a password in Passbolt, the password is currently displayed in clear text. This poses a significant security concern, as the purpose of a password manager is to securely store and manage sensitive credentials. I believe it is crucial to address this issue promptly by implementing measures to obfuscate or mask the exported passwords, such as using asterisks or other techniques to prevent their direct visibility.
and as an administrator, I would like to have the ability to define which users can export passwords. Having fine-grained control over this feature would allow me to restrict access to password exports for certain users or user groups, depending on their roles or the sensitivity of the passwords they have access to. This level of administrative control is essential to enforce security policies and minimize potential risks associated with unauthorized exporting of passwords.
Before trying to go for clarification, I just wanted to share that there’s a new incoming pro feature planed for the version 4.1.0 of Passbolt. It’s called RBAC (Role Based Access Control) where you will be able to defined that a given role is not able to do such thing as exporting the passwords or even do a preview of it.
About the export, when a secret is shared to a user, the user is able to access the cleartext part of the secret anyways. Not being able to export massively the secrets or not being able to preview a secret in Passbolt UI won’t block a user to access the clear text and save it manually somewhere else.
The only thing that could be done to avoid a user to decrypt a secret is to make sure the resource is not shared with that user. Actually from a cryptographic stand point, with Passbolt, when a secret is not shared with a user, that user cannot decrypt the secret. I mean it’s not just a logical flag manage by the UI or so, it’s actually encrypted PGP messages made for a specific recipient, so:
no share => no access
Notice that in case you need to know who had access to a resource they shouldn’t, you could be able to get log from the DB to know when a resource has been decrypted and by who (there should be a way a bit more convenient to read this data in the admin UI in another incoming feature called audit log currently planed for the version 4.2.0).
Also, if you export the secrets as CSV, you export in a format compatible with other systems. Those systems require the secrets in CSVs to be in cleartext to import them correctly. So yes, in CSV, the secrets have to be displayed in clear text.
There is the possibility to export the data in KDBX format which then requires a key or a password, so the resulting export is not in clear.
As promised, the 4.1.0 is out and brings the RBAC feature! The release notes are not out yet, but the server and the browser extension are already available if you want to take a look.
!