I am actually surprised this hasn’t been requested before, but I would like to see the ability to encrypt the content of certain fields in the database. Some data that is being stored would be considered senstive, for example medical data, and particularly within the EU (though I am sure elsewhere as well) should not be stored in plain text. Is this something that has been considered?
This is an interesting request, and I can see where it would have value. Gibbon has been developed outside the EU, however we do still take data privacy seriously. As such, Gibbon should always be hosted on an HTTPS enabled domain, so that all data transmitted between client and server is encrypted by default and not sent in plain text. I agree, the database itself is not encrypted, so with Gibbon being open source we’d be open to contributions that explore adding this functionality, as long as it fits with the core.
The tricky part of encrypting data like this is that should the encryption key ever be lost or changed, the data would be irretrievable. The encryption keys would also need to be stored on the same server as the database, likely in the filesystem, for the server to be able to access them during runtime. This means a server breach would still be a bad thing to happen, regardless of encryption.
Hi @sandra ,
Thanks for your reply and comments on this request. There is to my knowledge no legal requirement within the EU to store such data encrypted, as long as the connection is secured by SSL (as it is). It is just considered good practice for particularly sensitive data.
Your point about the keys being stored on the server is of course a valid one, though I imagine that if the server is breached enabling someone to access the key there are likely to be bigger security concerns.
Fair enough. It does look like MySQL has some built-in encryption functionality, and should someone have the capacity to explore this functionality, we’d be happy to discuss what that might look like.
Some options used with schools I’ve worked with is to password protect uploaded PDFs with a common key, for highly sensitive documents. Another option is to link to an external document that has it’s own access controls, such as a Google Doc with specific user access restrictions. It does put the information in the cloud, but Google has a lot more money and programmers protecting their data, and separating things in more than one location can be useful.
Yes, it probably shouldn’t be too difficult to implement this with PHP and MySQL. Ideally it would then be possible to select on a per field basis whether the data should be encrypted or not (for performance reasons). Unfortunately we don’t have the capacity right now to take this further ourselves, but perhaps somebody else is also interested in this functionality and does have the capacity to explore whether or not it would be feasible to implement as an option.
Documents are less of a problem and as you mentioned there are other solutions. I doubt many schools (certainly in the EU) would be allowed to store sensitive documents in a public cloud, but there are other options which respect data sovereignty. This request really only concerns database entries.
In any case, thank you for being receptive to the idea. Let’s see if anyone else sees a need for it.
If I can just add to this, as I mentioned the file uploads are not really the issue: If I understand correctly, any files uploaded via the system - attached to a student or otherwise - are obfuscated with a complex filename but ultimaely anybody who knows or discovers that file name will be able to download it directly. I realise that the upload directory can (and should) be protected, but that just means you have to be logged in to download. Potential problem (and again I am surprised it has not been mentioned before): If a student logs in to their account at a computer with shared access or a publicly accessible device, downloads a file and then logs out again, if a different student then logs in to that device they will have the obfuscated document link in the browser history. Because they are logged in, they will be able to download it. Or am I wrong here?
Sorry if I am seeing problems that don’t exist for the majority, but we have to tread carefully.
Hi @ccfu I appreciate your attention to data protection. In this case, if it was an attachment such as on a lesson plan (which are available to a whole class and not as private), then it may be saved. Although, in checking my own browser history, I don’t see that the full path to downloaded files is saved, only the referring page, which doesn’t have the attachment URL.
For the case of documents like reports and transcripts, this has already been considered. The files are not only stored with obfuscated names, but the name of the file is changed to a non-obfuscated name before it is downloaded by a user, so that they never directly see the path to that file in the system. Over time, we aim to use this approach for all files in the system.
Thank you @sandra for your detailed explanations.