In a discussion about encrypting email addresses for compliance with privacy and PII laws, nileshtrivedi asks if Discourse offers a built-in feature to encrypt email data at rest, especially to protect against SQL injection or insider threats. riking notes that while email access by admins is logged (with exceptions like backups), Discourse has no known SQL injection vulnerabilities, and suggests disabling email search/show features as a workaround. codinghorror recommends encrypting the server filesystem instead of modifying the application, calling it the most practical solution. nileshtrivedi follows up asking what would break if they override email-related methods to add encryption, and codinghorror strongly advises against it, warning that it would require maintaining a fork and is not a safe approach. The consensus leans toward infrastructure-level encryption rather than application-layer changes.
We are a financial organization and are required to comply with privacy laws of various countries that asks us to encrypt all “Personally Identifiable Information”. Email address falls into that category so we want to have Discourse setup in a way that users’ email addresses are stored in encrypted form and offer at least some protection against hackers, SQL injection attacks and/or rogue employees.
Is this feature available? If no, what’s the best way to implement this?
Oooh, that’s going to be a tough one.
Currently, when an admin or moderator views the email of an account, it is logged, except if an admin takes a backup and reads the email from there. So there’s a layer of protection against rogue employees, but it’s not foolproof.
SQL injection - Discourse has never had a SQL injection vulnerability, and I don’t think it ever will. There was one in Rails that got patched, but Discourse was never going to trigger it. What you need to be worried about is someone getting XSS on an admin and using that to extract sensitive data.
It sounds to me like you need encryption-at-rest of the emails, plus disabling the ability to Show Email or search users by email.
This also shares aspects with needs from medical organizations of anonymity of user accounts.
Just encrypt the server filesystem is my recommendation, then all data “at rest” is encrypted. Nothing else is really practical.
What are the things that would break if I implement encryption / decryption by simply overriding the getter and setter methods in the model? SQL queries on the email column will break for one. But what else?
You’ll have to maintain a fork.. this is a bad idea. Don’t play games here, just use the built in OS level filesystem encryption and be done with it.