search

ifmeorg / ifme

Free, open source mental health communication web app to share experiences with loved ones
http://www.if-me.org/
GNU Affero General Public License v3.0
1.49k stars 745 forks source link

Data security at record level #724

Open martijndeb opened 7 years ago

martijndeb commented 7 years ago

Description

As mentioned on the generic Slack channel; @julianguyen replied to this already.

Data in the database is of poor encryption value. The password field for users is hashed, but that's about it. I can't look if postgresql is configured to encrypt using pgp certificates at the live server, but that's something often overlooked.

Data should be encrypted at the record level as well in case of data theft / server breach. This might even be required in some countries. (For example, the Netherlands is thinking about that). And some organisations might require it before endorsing the if-me application.

As mentioned in the channel as well this might be accomplished using a transparant encryption engine. Crypt_keeper looks nice, but not sure if it's compatible with Rails 5. (https://github.com/jmazzi/crypt_keeper) also attr-encrypted might proof to be another option (https://github.com/attr-encrypted/attr_encrypted).

Also crypt_keeper is able to encrypt current tables on the fly, which would make sure that all data can be migrated quite easily.

Let's keep data secure!

Please assign yourself (via the Assignees dropdown), if you do want to work on this issue. Can't find yourself? You need to join our organization.

Check out our Picking Up Issues guide if you haven't already!

HashNotAdam commented 7 years ago

The challenge with this is that the database should already be firewall protected from communicating with any server other than the web server. This means that, if you wanted to steal the database, you would need to compromise the web server and, if you can compromise the web server, you could just download the database via Rails... which is going to need to be able to decrypt the data.

martijndeb commented 7 years ago

That's not entirely true. Different threats need to be mitigated in a different way. Say for instance postgres runs as a different user, and somehow postgres user was compromised or the interface exposes raw data on the web, you would still need application logic to decrypt the data.

What you are proposing is elevated access, but one wouldn't always get elevated access when breaching a machine. So say this is what happened, then you wouldn't require record level encryption, but the postgresql pgp encryption would suffice. But I don't see any configuration for that in the repo for that neither.

Enabling postgresql pgp certificates would still make the service prone to memory leaking errors, but if you are able to pull that off you probably have elevated access as well.

I still think this is a great improvement, and still a requirement for some organisations / law in different countries.