hiyaryan
commented
7 months ago Entries and conversations should be encrypted in the database. They still need to be made accessible to the server in order to generate reports and be used in other features that will maximize the mental health benefits attainable from the application. This means the users password cannot be used to encrypt it since only they know their password. Another downside of using their password is that they will have to be logged in and intentionally access an endpoint of the api to generate reports, ideally this should be done on the server once per week, for example, asynchronously, and then the user can log in and immediately see their results.
This means that there should be a key stored on the server that is used to encrypt these collections. The problem now though, is that all of the entries will be encrypted with the same key. While this key is secure on the server within an environment variable, consider the hypothetical situation where the key is leaked. Now all of the entries can be decrypted. However, the collections themselves are not associated with any specific user, so the identity of the user is protected. Ideally, we want each document to be encrypted with a different key. And each key needs to be accessible for the server to decrypt the documents so it may generate reports. These keys can either be stored in a separate database or collection. More research is needed.
User entries and their associated analyses and chat messages should be encrypted.
This can be done in a few ways, by providing a secret key for each user that can be cached in their browser similar to session id, or by using the users password which is already encrypted.
The first of these options can make it so that the client's browser performs the encryption (this is related to #41 adding client-side encryption).
The second of these options can be done on the server side (this risks overworking the server though).
It should be considered which of these options (or another) should be used, and which of these options will promise that the users data can be retrieved and properly decrypted when requested. There's a concern that if the key changes, the data will be locked forever.
The key should be updated occasionally, similar to passwords, but will this require re-encrypting all of the entries every time? That could iduce serious performance issues.