We are looking at migrating our Moodle site from a corporate Intranet to the Cloud. I know that our Security group is going to insist that all data-at-rest (as well as in transit) be encrypted. How badly is this going to break Moodle? Is it possible to make Moodle work with an encrypted database?
It will slow your moodle site down for sure - encrypted websites will run slower than non-encrypted ones. I am afraid I can't comment on an encrypted database though...
Please don't take this the wrong way but depression starts to fall upon me as soon as people start talking about "the cloud". If I may translate - you are moving from hosting Moodle externally to an external host. The latest buzzword IMHO.
If you are so worried about data security that we are even having this discussion then I have two suggestions....
1. Don't move to external hosting
2. Find a host you can (and your security people) will trust and can give appropriate assurances for the safety of your data. (Many hosting companies will have had security audits and other legal data-protection legals in place that they will be more than happy to share with you).
If you are so worried about data security that we are even having this discussion then I have two suggestions....
1. Don't move to external hosting
2. Find a host you can (and your security people) will trust and can give appropriate assurances for the safety of your data. (Many hosting companies will have had security audits and other legal data-protection legals in place that they will be more than happy to share with you).
Thanks for your response, and I'm sorry you're depressed but it's not necessary for you to translate. I am well aware of what "the Cloud" is.
Your first suggestion is not an option - it must be migrated. As for your second suggestion, we have already identified the host provider and have already reviewed all of their security processes and procedures. However, we still will be required to encrypt the data at rest.
My question remains: Will Moodle work using an encrypted database?
Ok, please excuse my sarcasm.
I have never heard of this being done. As far as I know adodb does not support such a thing but others may know better.
My final word on this is to strongly suggest that you have latched on to a possible solution when you might be better fully discussing the reasons for it.
I cannot see a situation where this would be a remotely sensible idea. For example, where are you going to put the keys to decrypt the database? In Moodle's config.php file, perhaps? Think about it - how is that any more secure than the database itself.
There is a lot of first class technology for locking down servers so that the possibility of somebody getting into the database is minimised but I cannot for the life of me understand how encrypting that database could or should be one of them.
Anyway, good luck with your Cloud
EDIT:
I forgot about this -
I have never heard of this being done. As far as I know adodb does not support such a thing but others may know better.
My final word on this is to strongly suggest that you have latched on to a possible solution when you might be better fully discussing the reasons for it.
I cannot see a situation where this would be a remotely sensible idea. For example, where are you going to put the keys to decrypt the database? In Moodle's config.php file, perhaps? Think about it - how is that any more secure than the database itself.
There is a lot of first class technology for locking down servers so that the possibility of somebody getting into the database is minimised but I cannot for the life of me understand how encrypting that database could or should be one of them.
Anyway, good luck with your Cloud
EDIT:
I forgot about this -
Another prime example of a moodle partner who should know better, but obviously knows very little.
The config file (on a properly secured site) is by far more secure than the moodle database. The database is the single biggest security hole in moodle...by far a bigger security problem than anything you've seen (or been forced to see) previously...the moodle_data problem and moodle porn problem (both of which still impact thousands of moodle sites today) doesn't even compare to the database security problem. If people knew just how insecure their moodle sites really are, there would be a lot of moodlers having trouble sleeping tonight.
The config file (on a properly secured site) is by far more secure than the moodle database. The database is the single biggest security hole in moodle...by far a bigger security problem than anything you've seen (or been forced to see) previously...the moodle_data problem and moodle porn problem (both of which still impact thousands of moodle sites today) doesn't even compare to the database security problem. If people knew just how insecure their moodle sites really are, there would be a lot of moodlers having trouble sleeping tonight.
Are you speaking of the typical mysql issues or of vulnerabilities on the moodle side? Clearly, one wishing a secure db would ensure that the installation architecture precluded public access to the mysql db ( a precaution often ignored ), but such matters, are of course, far different than an exploit employing moodle code to manipulate what would otherwise be a secure db. I take it you are talking about something more sophisticated than a direct crack attack on the mysql db?
Marc,
This isn't some simple, mysql username root with no password issue...it's a 100% moodle vulnerability.
Here is what I'm going to do. Since you seem to be one of the few independent thinkers around here these days, I'm going to send you a detailed video demonstration of the problem by the end of this week. Between now and then, I'll decide how I intend to make the problem known to a much wider audience.
This isn't some simple, mysql username root with no password issue...it's a 100% moodle vulnerability.
Here is what I'm going to do. Since you seem to be one of the few independent thinkers around here these days, I'm going to send you a detailed video demonstration of the problem by the end of this week. Between now and then, I'll decide how I intend to make the problem known to a much wider audience.
Well, the responsible way to report Moodle security problems is to file a bug at http://tracker.moodle.org/, marking it as a security issue.
(This is explained in the security FAQ Security_FAQ#How_do_I_report_a_security_issue.3F, and in the introduction to this forum.)
(This is explained in the security FAQ Security_FAQ#How_do_I_report_a_security_issue.3F, and in the introduction to this forum.)
This is perhaps the least constructive post I have ever read...
I'm not going to reply in this thread again, but hold that thought...
Oooh. A little deja vu moment
Gentleman,
While I enjoy a spirited debate as much as anybody, the purpose of the forums is to provide guidance and assistance. I do appreciate when someone tells me something is a bad idea, and why it is a bad idea, but I also appreciate when a better solution is offered. In order to get this discussion back on track, here are the facts:
- We must migrate to a host outside our corporate firewall
- As much as 60% of data theft comes from internal sources (source), which is one of the reasons our corporate policy specifies that data-at-rest be encrypted
- While we maintain a minimum of personal data about our students, a very large portion of our training material (ours and our clients) is proprietary.
Given these facts, the question remains: Is it possible to encrypt the MySQL database without breaking Moodle, and how is this accomplished?
Interesting. From a quick Google it looks like Postgres has the kind of features you want. http://www.postgresql.org/docs/8.4/static/encryption-options.html. I did not know that sort of thing existed.
The thing I don't get - and I'm more than prepared to be educated - is that if you don't trust your hosting provider (which I think is what the OP is fundamentally saying) then who holds the decryption keys? I can't imagine a scenario where (given that Moodle is scripted not compiled, particularly) where someone with free access to the server could not access the decrypted information.
BTW... for the avoidance of doubt I just wanted to know why this was required because I've genuinely never seen it asked before. I still think that if you don't trust your hosting company to look after your data you are going to have a difficult time. Ultimately with sensitive data you have to trust *somebody*.
EDIT:
Having skimmed that article I suppose I have to concede that it would be one more thing for a data "thief" to get by if some administrative error left the database open.
Yet another reason to use Postgres
EDIT EDIT:
What are the training materials? If they are SCORM or somesuch then they're not in the database at all. Question coming up - can you encrypt the 'moodledata' directory? More data-at-rest. That would definitely require some hacking in Moodle.
BTW... for the avoidance of doubt I just wanted to know why this was required because I've genuinely never seen it asked before. I still think that if you don't trust your hosting company to look after your data you are going to have a difficult time. Ultimately with sensitive data you have to trust *somebody*.
EDIT:
Having skimmed that article I suppose I have to concede that it would be one more thing for a data "thief" to get by if some administrative error left the database open.
Yet another reason to use Postgres
EDIT EDIT:
What are the training materials? If they are SCORM or somesuch then they're not in the database at all. Question coming up - can you encrypt the 'moodledata' directory? More data-at-rest. That would definitely require some hacking in Moodle.
Thanks Howard - great questions. Our Moodle database is on a different server than the application, and would use the same arrangement when migrated, so to my thinking, the encryption key would be on the application server, not the database server. Not sure if this is even possibe, or if Moodle can even work with an encrypted database, but that's why I'm asking the questions here.
As for trusting the host provider, they are solid, reputable, and all the contractual agreements are in place (we already have a relationship with them for other hosting). That being said, a legal contract has little meaning to unethical employees or hackers. If the data is stolen, contracts and assurances mean little. Encrypting the data adds another layer of security to an application supporting a finance-related business.
Regarding your final point, some of our content is SCORM (and we're always busy converting more), and the balance is in a variety of formats (Word, PPT, PDF, Flash Video, etc). We are working toward securing that content, but my current concern is the material that IS stored in the database - quiz questions, etc. It may even come down to converting the Quizzes to SCORM modules housed on our media server (complete with 128 bit encryption).
It looks like "Encryption For Specific Columns" is the most interesting one (and I'm not aware of MySQL supporting that). "Password Storage Encryption" (AFAIK) and "Data Partition Encryption" apply to MySQL as well ("Data Partition Encryption" is a function of the operating system, and not the database). I'm not sure about the network side of things for MySQL, but at worst, you could probably fake an SSL tunnel using something like stunnel. "Client-Side Encryption" would require changes to Moodle (and would most likely break indexes and other stuff).
But (to the OP), as others have mentioned, encryption is no silver bullet. You need to identify what risks you are trying to protect against, and determine whether encryption actually solves those issues. For example, encryption won't do anything if the people you are trying to protect against have access to the encryption keys.
But (to the OP), as others have mentioned, encryption is no silver bullet. You need to identify what risks you are trying to protect against, and determine whether encryption actually solves those issues. For example, encryption won't do anything if the people you are trying to protect against have access to the encryption keys.
Hmm, encrypting of database solves very little for you - each php script in moodle needs to access database and filesystem - that means it has to have access to these. Simple exploit is to modify or add one php script and you have all the needed information/access.
Moodle is not designed for data protection like banking software, it is designed to allow teachers to create learning content, enable communication between users, etc. We can not make Moodle as secure as banking sites, for example we need to allow users to upload and share content - this is absolutely unacceptable for any banking software.
In Moodle we have to trust our teachers, unfortunately we do not have any other option. The students are on the other hand not trusted, we remove any javascript code or scripted content, we intentionally cripple uploaded files via forced download. All other learning systems both open source and proprietary have to do something similar - there has to be somebody who is allow to upload SCORM packages (html+mixture of arbitrary javascript, flash and java applets). We need to allow students to upload assignments.
Very often people ask "How to protect my Intellectual Properly" that I share on my server?" Answer is simple, you can not. There are no artificial restrictions preventing sharing of information on web, some companies tried to invent various Digital Management Rights systems but they all failed. If I can display something in my browser I can always make a copy of it, sorry.
If you really want "secure" system you have to:
* control physical access to server
* encrypt the whole operation system and all disk partitions in general
* manually enter decryption password or supply keys during each boot
* do not allow any internet access at all
* do not use any webserver that accepts data from users
* etc.
In case of hosted servers you do not control physical access, anybody can mess with your boot loader and can gain full access. Even using preboot full disk encryption can work because you can not go to the server room and supply passwords during each boot securely.
To sum it up: the weakest link of the chain always fails first - in this particular case the security/privacy of data in database is not your biggest problem.
EDIT: sorry for the typos, must read before hitting enter next time
Moodle is not designed for data protection like banking software, it is designed to allow teachers to create learning content, enable communication between users, etc. We can not make Moodle as secure as banking sites, for example we need to allow users to upload and share content - this is absolutely unacceptable for any banking software.
In Moodle we have to trust our teachers, unfortunately we do not have any other option. The students are on the other hand not trusted, we remove any javascript code or scripted content, we intentionally cripple uploaded files via forced download. All other learning systems both open source and proprietary have to do something similar - there has to be somebody who is allow to upload SCORM packages (html+mixture of arbitrary javascript, flash and java applets). We need to allow students to upload assignments.
Very often people ask "How to protect my Intellectual Properly" that I share on my server?" Answer is simple, you can not. There are no artificial restrictions preventing sharing of information on web, some companies tried to invent various Digital Management Rights systems but they all failed. If I can display something in my browser I can always make a copy of it, sorry.
If you really want "secure" system you have to:
* control physical access to server
* encrypt the whole operation system and all disk partitions in general
* manually enter decryption password or supply keys during each boot
* do not allow any internet access at all
* do not use any webserver that accepts data from users
* etc.
In case of hosted servers you do not control physical access, anybody can mess with your boot loader and can gain full access. Even using preboot full disk encryption can work because you can not go to the server room and supply passwords during each boot securely.
To sum it up: the weakest link of the chain always fails first - in this particular case the security/privacy of data in database is not your biggest problem.
EDIT: sorry for the typos, must read before hitting enter next time
Security is a process not a destination. You can have the worlds most uncrackable encrypted file system or database but as soon as someone overcomes the security in the systems that are able to access that file system or database you have no security. Your weakest links are probably your staff/teachers.
In summary, If you do manage to encrypt the database or file system, the system probably won't be any more secure than before you put in that effort.
In summary, If you do manage to encrypt the database or file system, the system probably won't be any more secure than before you put in that effort.
But you can be assured that the system will be much slower........ your web server will be both encrypting and decrypting talking to mysql server and I assume doing the same via SSL to the browser.
I have no doubt that it will be slower, but our Security group isn't concerned with that <sigh>.
Has anybody used ezNcrypt for MySQL? It looks like it might do what I need without breaking Moodle.
I think you may be on to something with ezNcrypt. I hear it is a Transparent Data Encryption solution. It encrypts the data between the database and disc. It's transparent to the application and database so no changes are necessary at all. Just a simple install, then you chose the database tables you want to encrypt. You only encrypt what is necessary, so the performance hit is negligible.
I know people who are using this to encrypt credit card information on application servers for PCI DSS compliance, and heard of someone who is using it to protect intellectual property on a back-end web server.
Key management is the biggest bonus here. It's all automated as part of the solution. Check it out at www.critotech.com .
I know people who are using this to encrypt credit card information on application servers for PCI DSS compliance, and heard of someone who is using it to protect intellectual property on a back-end web server.
Key management is the biggest bonus here. It's all automated as part of the solution. Check it out at www.critotech.com .
I have been stewing about Petr's comment and I guess I have decided I am concerned enough to want to clear things up a bit.... And, despite the risk that I might sound less than neutral to some 
} I have talked myself into sticking the old toe in the water.....
In the U.S. there is a federal mandate, FERPA, regarding the securing of student data, and the law does not suggest that student data is less important or valuable than banking data (heavens, while I am sanguine over the matter, I hope our educational system is in better shape than our financial system!) If Moodle can't be expected to keep student data secure than it could not be used in at least the US or the UK. I am guessing, however, that Petr was being hyperbolic to make his point, yes? If anyone really feels that Moodle can't be expected to maintain student data confidentiality and integrity I think that would be something to air PDQ, no?
In any event, while I largely agree with Petr, his suggestion that, "In Moodle we have to trust our teachers, unfortunately we do not have any other option" may not make it clear to users, especially newbies (FF advises me that newbie is the correct spelling - lol)
that anyone with the ability to backup a course in Moodle essentially has admin access. In other words, your site is never more secure than your least trusted teacher 
. Based on prior discussion many here would state that this situation is not a "security issue" but it may nevertheless come as a surprise to many new to Moodle.
Of course I may be misinterpreting/misapplying the arguments of Inaki and others as made in the discussion concerning profile spam, so it is only fair to ask, "Is there any disagreement with the above point?" If there isn't, I suppose the next question is, "Should the newbie be advised of this?" And that would be followed by, "Where is the documentation that might apprise the newbie of this?"
While this is a bit off topic vis-a-vis the OP, I thought as long as the issue was raised here it was worth addressing here. What say you?
Marc,
I agree the topic is worth raising and should be considered when deploying Moodle for public education. Because we use Moodle for corporate training, we don't fall under the FERPA umbrella, but that doesn't mean we're any less concerned with security.
As for trusting our teachers (facilitators), that's not the issue I'm trying to address. My main concern is how to protect the data should a greedy, unethical, or just plain nosey employee at the hosting company decide to have a go at the data. I've long known there is no such thing as data security, but we can still strive for a more secure database. From my point of view, if someone's going to steal my data, they're gonna have to work for it! 
Hence, the need for an encrypted database.
As for making noobs aware of the security risks, the Moodle team does as good a job, if not better, of staying on top of security issues as most software 'vendors', and the information regarding risks and recommendations is readily available. It's up to the new admin to read/subscribe to the appropriate information.
Don't get me wrong Robert, I think it's great that your security conscious, but it always boils down trusting someone, and frankly I think you probably have more to fear from your facilitators, who have some idea of the value and use of your resources, than the web host. ;)
Also, discussion here has at times become heated over just what is a security risk. If you hired me to administer your moodle would you expect me to tell you that your teachers can gain admin access. I don't think your going to find that point discussed anywhere at moodle.org...
It always comes back to balancing cost and convenience. I will be very interested to see what you eventually decide to do and I encourage you to keep looking for a solution.
Also, discussion here has at times become heated over just what is a security risk. If you hired me to administer your moodle would you expect me to tell you that your teachers can gain admin access. I don't think your going to find that point discussed anywhere at moodle.org...
It always comes back to balancing cost and convenience. I will be very interested to see what you eventually decide to do and I encourage you to keep looking for a solution.
Marc,
Yes it does always come down to trusting someone. I have worked as a system admin for some big companies. And I have access to *everything*. You might not like it but I do. You can encrypt personal data but if you encrypt system databases for web servers than - if I can be bothered - I can probably trivially access that data too.
Unless things are to get really weird then that's not a bad situation. However, good management dictates that you minimise the number of people who have that level of "power".
I have heard this conversation cut a number of ways over the years and it's often when the penny drops to some manager that the IT people can access their payroll data.
You have to trust somebody!
Yes it does always come down to trusting someone. I have worked as a system admin for some big companies. And I have access to *everything*. You might not like it but I do. You can encrypt personal data but if you encrypt system databases for web servers than - if I can be bothered - I can probably trivially access that data too.
Unless things are to get really weird then that's not a bad situation. However, good management dictates that you minimise the number of people who have that level of "power".
I have heard this conversation cut a number of ways over the years and it's often when the penny drops to some manager that the IT people can access their payroll data.
You have to trust somebody!
Hello,
we try to fix all problems we find or that get reported, sometimes the solutions are a bit complex and it takes some time to get it implemented. Unfortunately the main "security problem" is in the browsers and the whole design of web. Web was designed for distribution of information, not as a security framework
It is always better to not put sensitive data into any web based system and instead keep it outside in some locked down database.
There are many configuration options in Moodle that help you get the desired compromise between security and flexibility. We can not make the default Moodle install fit all regulations and school needs world wide, you have to:
* educate the admins
* configure moodle properly
* educate teachers
* maintain your moodle regularly
To everybody: Please do not blame the developers that Moodle is not "secure", it is definitely not worse than other similar systems. Instead please help us create better documentation and guides for admins and teachers.
Petr
we try to fix all problems we find or that get reported, sometimes the solutions are a bit complex and it takes some time to get it implemented. Unfortunately the main "security problem" is in the browsers and the whole design of web. Web was designed for distribution of information, not as a security framework
It is always better to not put sensitive data into any web based system and instead keep it outside in some locked down database.
There are many configuration options in Moodle that help you get the desired compromise between security and flexibility. We can not make the default Moodle install fit all regulations and school needs world wide, you have to:
* educate the admins
* configure moodle properly
* educate teachers
* maintain your moodle regularly
To everybody: Please do not blame the developers that Moodle is not "secure", it is definitely not worse than other similar systems. Instead please help us create better documentation and guides for admins and teachers.
Petr
In response to Marc, I would say that I would be much more upset if a Hacker transferred all of the money out of my bank account, than if they stole all the information about me in the OU's student information system. (I am an OU student, as well as a staff member).
(How would I fell if a Hacker wiped all record of the courses I had successfully completed? That is a more interesting comparison ... but then I do have paper certificates. More importantly, they can't (yet!) hack my brain and remove what I have learned.)
To add to what Petr just said, I will point out that the new Security Coding Guidelines I wrote try to briefly explain the various types of vulnerability that Moodle can be exposed to, as well as telling developers what to do to avoid them. I also added some advice for administrators. Anyway, if you are interested in this topic, you might find those guidelines worth a read. Also, they are relatively new, so I am sure there are still mistakes and omissions to find. Please feel free to improve them.
I'm finding this thread very interesting. Thank you everyone for your contributions.
(How would I fell if a Hacker wiped all record of the courses I had successfully completed? That is a more interesting comparison ... but then I do have paper certificates. More importantly, they can't (yet!) hack my brain and remove what I have learned.)
To add to what Petr just said, I will point out that the new Security Coding Guidelines I wrote try to briefly explain the various types of vulnerability that Moodle can be exposed to, as well as telling developers what to do to avoid them. I also added some advice for administrators. Anyway, if you are interested in this topic, you might find those guidelines worth a read. Also, they are relatively new, so I am sure there are still mistakes and omissions to find. Please feel free to improve them.
I'm finding this thread very interesting. Thank you everyone for your contributions.
My deposits are insured, but if my kid is being stalked by a predator or harassed because of a condition that is confidential there is no simple solution.
We are in part talking about child safety and it seems that the discussion has acknowledged that moodle is only as secure as your least trustworthy teacher and that there is nothing in the docs actually explaining this....
In part I think this is still the same argument over whether a feature is a security issue. In other words, if a moodle exploit can be thwarted through configuration, then coders argue there is no security issue. But that's like handing a loaded gun to a kid. Do enterprises using moodle understand that teachers can get access to the entire moodle db? I don't think we can sit here and say Moodle meets FERPA requirements with advising the new moodle admin of the configurational security threats. Remember, it is quite common for teachers to give student assistants passwords, and in doing so the teacher just put the entire moodle at risk.
We are in part talking about child safety and it seems that the discussion has acknowledged that moodle is only as secure as your least trustworthy teacher and that there is nothing in the docs actually explaining this....
In part I think this is still the same argument over whether a feature is a security issue. In other words, if a moodle exploit can be thwarted through configuration, then coders argue there is no security issue. But that's like handing a loaded gun to a kid. Do enterprises using moodle understand that teachers can get access to the entire moodle db? I don't think we can sit here and say Moodle meets FERPA requirements with advising the new moodle admin of the configurational security threats. Remember, it is quite common for teachers to give student assistants passwords, and in doing so the teacher just put the entire moodle at risk.
MS and other companies creating browsers or browser plugins are releasing security fixes every week. If somebody gets access to your computer directly you are in much bigger trouble than if somebody gets access to your Moodle data. Are you proposing to not allow children to use Internet?
I am personally more scared from blogs, twitter, facebook and other Web 2.0 things - children do not send highly sensitive and personal information into their schools' Moodle, they do send it into these systems without any thinking
Some time ago new feature was added into Moodle - the security overview report. This tool is designed to help administrators configure their Moodle servers.
Petr
I am personally more scared from blogs, twitter, facebook and other Web 2.0 things - children do not send highly sensitive and personal information into their schools' Moodle, they do send it into these systems without any thinking
Some time ago new feature was added into Moodle - the security overview report. This tool is designed to help administrators configure their Moodle servers.
Petr
Hi Petr,
after Martin's post today as reaction to someones irresponsible behaviour of posting and detailing security issues public on youtube I followed this discussion and must say I am very disappointed and disgusted on how some people who obviously want to damage moodle's reputation keep pulling out the most strange arguments. I absolutely agree with your postings on the trust we need into teachers - but also students and want to stress the fact that this is not a moodle problem but a social problem nowadays- we need to educate kids and students to keep them safe and make them use social media in a responsible way. THIS is the task for us teachers and I am ever so grateful that there are people like you out there in the moodle community who with their work and dedication help us fulfill these tasks!
Thanks again!
after Martin's post today as reaction to someones irresponsible behaviour of posting and detailing security issues public on youtube I followed this discussion and must say I am very disappointed and disgusted on how some people who obviously want to damage moodle's reputation keep pulling out the most strange arguments. I absolutely agree with your postings on the trust we need into teachers - but also students and want to stress the fact that this is not a moodle problem but a social problem nowadays- we need to educate kids and students to keep them safe and make them use social media in a responsible way. THIS is the task for us teachers and I am ever so grateful that there are people like you out there in the moodle community who with their work and dedication help us fulfill these tasks!
Thanks again!
Did I miss something? Where did Martin post on the 17th about this? In any event, I think almost anyone would have assumed that this "feature" was widely understood as no one seemed to have an issue with the suggestion that a Moodle was only as secure as the least secure teacher. In most respects this was no more a security flaw than addressed in the discussion of profile spam. You can configure Moodle so as not assure no impact. And as in that situation, arguably little had been done to promote avoidance of potentially dangerous behavior until public attention was called to the matter, though it was internally discussed for months prior to that. The argument with respect to the profile spam issue was that it did not reflect defective code, and arguably that may be true, but the same is true here. Certainly it was known that when you do a course backup of everyone you get a full backup. Likewise I found it hard to believe that the Moodle devs did not know about the existence of Rainbow tables. The assumption would have to be then that they knew that teachers with backup rights had access to weak passwords. Not a big deal if you trust your teachers, and after all, this is not a bank we are talking about, its just your 8 year old's elementary school.....