Forum for discussing general topics related to Couch.
7 posts Page 1 of 1
I've found two threads relating to encryption of data at rest and to Couch's GDPR-readiness, but I don't think either quite covers what I think I need.

I'm creating a site for a religious group within our diocese. Part of the requirement is for members to be able to access some 'internal' information - the first step is meeting minutes, but there will be more.

Since membership of the group implies membership of the religion, any personal details are 'sensitive personal data' under GDPR. Encryption at rest is therefore highly desirable (and at least arguably necessary).

There's an encyption solution for front-end data in the forums, but this won't help here as it says it doesn't work with the site control panel. Membership of the site has to be approved by the admin, so has to be in the control panel, as does the meeting data (which includes names of those attending, so again sensitive data).

Is there any solution for this - or even any way of making the whole database for a Couch site encrypted?
any way of making the whole database for a Couch site encrypted?

No. I don't think that is even possible.

At best, we can attempt to create a new kind of 'text/textarea/richtext' region that stores its data in encrypted form.
This will require creating a custom addon. It will also mean that these regions cannot be used in MySQL queries e.g. as made by <cms:pages custom_field="xyz"> - because the data is not plaintext (so basically we can only store and retrieve data from them).

Also, referring to the post you mentioned (viewtopic.php?f=8&t=10708&p=27059&hilit=encryption#p27050), if the password is stored on the same server, I don't quite see how an encrypted data would help in case the server gets compromised.
Hi, KK - thanks for the response.

I do see the issue with storing the encryption key on-site, and I think that was actually mentioned somewhere in the thread I linked [edit: it's in the comments in the encryptdataboundforms.php code]. Encrypted data in the database is at least an additional layer of difficulty for any attacker without full server access, though, and there are ways of storing the key separately.

I'd also been thinking a bit more since posting, and I think what I'd really like to see would be something like

Code: Select all
<cms:editable  type='text' name='my_sensitive_field' label='Political Party' desc='Which party do you support' encrypt  />


where the 'encrypt' parameter indicates that data is stored in an encrypted form, and it's simply a recognised consequence of using this that you can't search on that field. There'd also need to be some sort of error handling for the situation in which someone didn't notice that restriction and tried to search on an encrypted field.

Does that sound a feasible approach?
Yes, it does.

I'd be interested in knowing where and how you propose to store the encryption key.
Please let me know the details.
That's triggered some interesting discussions with people... :-)

Given that the intention here is to provide a layer of security against attacks via the web, and not to protect against any attack requiring physical server access (the site is cloud-hosted and physical security is to a sufficient degree the host's problem), I'm thinking of keeping the key within the server file structure but outside the web root. Could we work on that basis?
Hi, KK - just wondering whether you'd had any chance to think about this?
I think KK is right - there is little point encrypting the database content if the key (even if it's stored outside of the web directory structure) is readable by code which runs _in_ the web directory structure. Compromise the site, and write/run code to access the very same key.

To be really secure you'd need a public/private key system, with the private key decrypting as required _in your browser_. Public key, stored on the server, to encrypt and store the data. Couch could do this part for you in PHP .

Decryption would then need to be done client-side in the admin's browser using their private key - you could do this with the open source library crypto.js.

This would mean all admins needing access to the data would need access to the private key - but apart from that issue (which can be overcome) it would be 'extremely' secure so long as your own computer, or that of another admin, wasn't compromised.

Here's a thread on how to achieve this:

https://stackoverflow.com/questions/243 ... t-cryptojs
7 posts Page 1 of 1
cron