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?
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)
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.
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.
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 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
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.
Some of the scope of this feature is covered by encrypted description with v3. Leaving this thread open in the backlog until we implement more resource types and let admin decides which one to use.
@remy imo, not having metadata encrypted leaves the door open for nation-state threat actors to snoop easily on the metadata.
Https can’t fully be trusted because until recently there have been several attack vectors including one where a sufficiently sophisticated adversary could reverse engineer the handshake and reveal all https communications.
What would the level of effort be like to decrypt everything client-side? I imagine it wouldn’t be as simple just decrypting everything and putting it in a client side hash map. Has there been any work done to spec out a secure solution here that supports search? e.g. isolated memory sidecars with strict access controls for secret retrieval.
Historically the non-encrypted data in Passbolt include the URL and username, as these information on most web-based systems are already “leaked” via invitation email or email validation when the user signs up for the service. I agree however it’s not ideal, as you mentioned in your other thread.
There is some effort scheduled next year to allow administrators to control which metadata are encrypted or not, including username and urls (and create more content types, like SSH keys, credits cards, etc.). There are several approaches one “simple” one would be to reuse and extend the secret to include these fields for such resource types (like encrypted description). One more advanced one would be to encrypt the metadata altogether, except the name, modification date, etc. and keep them separate from the secret itself (passwords, etc.), in order to track access to both properly. This is one of the major objectives for this year, we’ll most likely share some specs late Q1 / early Q2.
One might consider everything to be a secret - metadata and passwords included.
Recently, I took a look at the data model used by passbolt since I was having issues importing the kdbx export into keepass (the issue was caused by a weird encoding for empty descriptions - \b0001 or something like that- not sure if that’s a passbolt bug or a bug from a previous export).
Instead of having secrets contained as encrypted json per resource how it’s currently done, one way to think about this is that every type of metadata should be a resource itself which can be encrypted.
For this I would propose 2 new resource types: a record type and a metadata type. Each resource of type record would make reference to metadata resources. In normalized form this would suggest a lightweight resource table ( id, resource_type_id, user_id, label_id, content, encrypted ) and a table to join records with metadata.
The label of a record would be NULL whereas metadata labels could be email, password, url, username, etc.
To simplify search, one could decrypt metadata resources where label is username, name, etc. without having to decrypt passwords.
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)