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

Backlog
#1

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:

  • :ok_woman: Must have: this is critical for me to have this
  • :raising_hand_woman: Should have: this is important for me to have this
  • :tipping_hand_woman: Could have: this could be nice to have
  • :no_good_woman: Won’t have: we should not schedule this (explain why)

0 voters

Show results
As an administrator I can create new secret types and define their associated input fields
Can I store file in place of the passwords?
#2

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.

2 Likes
#3

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.

#4

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).

#5

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

–
Patrick

1 Like
#6

@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