As an admin I should be able to select which fields are encrypted

[passboltUser]

Q1. What is the problem that you are trying to solve?
Text in the description can be sensitive and I wonder it’s planned to encrypt the description as well?

Relates to: As an administrator I can create new secret types and define their associated input fields

Q2 - Who is impacted?
Everyone with sensitive data in the password’s description or who want to write some things in there but can’t because it’s not encrypted.

Q3 - Why is it important and/or urgent?
It’s not uncommon to write certain other sensitive data to a password’s description field.

Q4 - What is your proposed solution? (optional)
Encrypt the password’s description the same way the password is encrypted.

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)

[palant]

I think that ideally all password metadata should be encrypted on the server, meaning in particular website and user name. This way a compromised server won’t expose further attack targets. This requires moving the application interface into the extension first however.

[OdyX]

The issue there is search. You want to be able to find secrets somehow. And having multiple columns readily available from the DB speeds this up massively. That said, it would be nice to have a long field that’s also encrypted (similar to As a user I can create resources with encrypted file attachement ). My point is: keeping some fields unencrypted makes a lot of sense.

[passboltUser]

Or make a button ~“Decrypt for search”, which temporarily decrypts all or selected fields? (no need to press/have an Encrypt button, as the decrypted data is stored temporarily in the browser page of that user).

[pbulteel]

I know we’re using GPG here for most of the data, but why not have the DB encrypt those fields.

Data-at-Rest Encryption Overview

–
Patrick

[remy]

@pbulteel what you are suggesting I think will only affect “data at rest” encryption, it won’t provide end to end encryption like GPG. This is a good solution that can be already be used, it is helpful to mitigate risks for example if a server is seized. The FAQ touches on the subject briefly: https://help.passbolt.com/faq/security/what-is-encrypted

[drzraf]

IMHO data should be either e2e-encrypted either searchable.
Whether it’s configurable or not by the user is debatable. But introducing non-e2e encryption here would create confusion about the security model expecting the same one for password and encrypted descriptions.

I’d suggest to just add an “encrypted description” and keep the search working as usual.
Users having sensitive descriptions would use it, backward compatibility would be maintained and you wouldn’t have to deal with a “encrypt description” checkbox and the confusion of having two different kind of data/data process living within one MySQL column.