Protecting information contained within or related to the course is important. We will try to establish potential weak points in accessing course data and ways to eliminate them or at least reduce the exposure. This primarily focuses on course backups since they treat potentially sensitive user information.
Moodle offers a possibility to create backups of your courses. This feature is essential in maintaining history of changes within a specific course and also offers safeguard against any potential errors or hardware crashes. You should be aware of the backup process in greater detail in order to better understand potential pitfalls and security problems that may occur.
During course backup process Moodle offers a possibility to choose which parts of a course we want to save. By default only users with Administrator or Teacher role can perform course backup. If user has moodle/backup:userinfo capability enabled then he will be able to take the backup of user data, user accounts and their role assignments within course, course activity logs, and user profile pictures. User data consists of all files submitted by users, forum posts, glossary entries, etc. Only Administrators have this capability enabled. Have in mind that this description applies to Moodle starting from 1.9.7.
In older versions of Moodle both Teachers and Administrators where enabled to perform full course backups with complete user information including hashed passwords.
In web applications passwords are almost never stored in clean text format since that is considered a security breach. To avoid storing such sensitive information directly developers usually hash passwords and store that value. Password hash is a result of deterministic procedure that takes an arbitrary block of data (in this case user password) and through specified mathematical process (hash algorithm) produces fixed size string.
Until recently it was established as sort of de facto standard to use MD5 hash algorithm for protecting passwords. It became so popular that various public hash databases appeared online like http://www.md5decrypter.com/. If somebody got a hold of a hashed passwords generated with MD5 algorithm he could pass them through one of these databases and possibly recover at least some of them. Have in mind that all these sites do not actually decrypt the hashed password since that is not possible. What they do instead is compare the hash against the previously stored list of known hashes, usually based on most common, insecure, password patterns like dictionary words, etc.
To make use of these sites obsolete developers started adding so called salt values. The salt values are randomly generated string of characters added to the actual password value prior to generating hashed value. Using this approach no MD5 decrypted site will be able to decode such hashed password.
Let us test this. For example, if we take a really insecure password 1234 and a random salt value of $%#qw!. These are the hash values we will have:
|
Password |
Salt |
Hash |
|---|---|---|
|
1234 |
| |
|
1234 |
$%#qw! |
|
If we go to the http://www.md5decrypter.com/ and try both hashes these are the results we will have, first for unsalted hash:
And then for salted hash:
Older versions of Moodle did not use password salt for higher password protection. Therefore, anybody with the hash database could easily break at least some passwords and thus illegally obtain access to the platform.
If you maintain Moodle instance prior to 1.9.7 then we strongly recommend you to do an upgrade. If that is not a viable option then do the following steps to secure your system:
A password policy is a set of rules designed to enhance computer security by encouraging users to employ strong passwords and use them properly. Using such policies makes password theft much more difficult. To enable this feature visit the Site policies page and check the Password Policy option.
Password salt increases the security of the generated encrypted password hashes, making a dictionary attack virtually impossible. This is done by adding a random stream of characters prior to the actual password before the hash is actually generated. By using this feature even if somebody obtains a course export it will be hard to get any useful data. See Chapter 1 for details on how to enable password salt.
In Moodle prior to 1.9.7, backup and restore of the courses was handled with three capabilities -moodle/site:backup, moodle/site:import, and moodle/site:restore. By default Administrator and Teacher roles had this enabled. Administrators should have this enabled but leaving this open to the Teachers may invite potential dangers. For example, a teacher could choose to export all user accounts in some course and then just by simply modifying a password hash for any user he would get access to those accounts once he imports the modified course backup again. To avoid this and other exploits, in the latest version of Moodle (1.9.7+) a teacher can only back up course data and cannot restore users (1.9.8+) even if they are present in the export. Since we cannot modify this behavior in older versions of Moodle the safest thing would be to disable these capabilities for the Teacher role. To do that visit the Define roles page (Administration | Users | Permissions | Define roles) and set the backup/restore/import capabilities to not set.
Individual course backups—the ones performed from within the course are always stored within a default course backup directory. Default course backup directory is located in this path<Moodledata path>/<course id>/backupdata. Access to this directory is available to any user who has enabled moodle/course:managefiles capability. This is a case with Administrators and Teachers. You can access course file directory through administration block within course.
Imagine a situation where an administrator performs a manual single backup of a course and leaves the file without deleting it. Any user with access to this directory will be able to freely access this export. He can also download it, replace it, or even delete it! The best practice in this case would be to create a backup and move it to some location only accessible to the administrator thus effectively removing it from Moodledata or if the administrator does not have direct access to the server resources he could just download the generated backup from Moodle and then delete it on the server.
One way of preventing this would be to disable the access of the teacher to course files. This is not the recommended course of action as it would seriously cripple the teacher's ability to create courses. He would not be able to upload or link any file within a course. The real solution to this problem is to never store course backups within course directory. It effectively means that Administrator should never create backup from within a course. Backups should always be performed by scheduled backups utility.
Scheduled backups offers a possibility to execute batch backup of any course within your platform at any desired moment. This way of making safe copies of your platform structure also offer a possibility to store the actual backups outside the course directories. To configure this visit the Administration | Courses | Backups page and locate the Save to text field. In there set the path to an external folder somewhere outside your Moodledata directory.
On Linux execute this to create such a directory:
/bin/mkdir /var/www/backupdata/
/bin/chown -R root:apache /var/www/backupdata/
/bin/chmod -R ug=rwX,o= /var/www/backupdata/
On Windows open elevated command prompt and execute this:
mkdir Z:ackupdata
icacls Z:ackupdata /Q /T /inheritance:r
icacls Z:ackupdata /Q /T /grant Administrators:(OI)(CI)(F)
icacls Z:ackupdata /Q /T /grant moodle:(OI)(CI)(F)moodle:(OI)(CI)(F)
You can use daily scheduled backup as a crash recovery strategy. You will be able to easily recover any course stored in the backup. Have in mind that this is very resource intensive operation, so choose wisely a time where you want to run it, preferably when you have low number of users accessing the platform.