Securing Moodle Data


Moodle Security

Moodle Security

Learn how to install and configure Moodle in the most secure way possible

        Read more about this book      

(For more resources on Moodle, see here.)

User information protection

Every user within Moodle has a profile which can contain information we may or may not want to show to other users, or at least not to all of them. The level of exposure will depend on the privacy policy we want to adopt. For example, we may want to completely isolate users within a course so that nobody knows who else is participating, or we may want to expose just the user names and nothing else, and so on. Let us first describe how Moodle handles presentation of user profiles. This is important as it will expose internal workings of that subsystem and identify all access points and ways of disabling them if that is what we want to do.

User profile page

User profile page is used to define personal information about a user within a Moodle. It can contain name, surname, address, telephone, etc. The user profile page is reached by <Moodle URL>/user/view.php?id=<userid>&course=<courseid> where userid and courseid are identifiers of user and course as they are stored in database. This is how Moodle determines whether to show or not the profile page for a particular user:

Logged-on user

User to see


Show profile


Other user

Other user is teacher in at least one course




User is teacher in at least one course





User has View user profiles capability enabled in current context




None of the above






When we say teacher we refer to the Moodle roles Teacher and Non-editing teacher.

Reaching profile page

There are several ways a user can reach the profile page for a particular user. We are presenting them here in order to help the administrator to block potentially unwanted access points to user information.

People block

Every course upon creation gets a set of predefined blocks. One of these blocks is the people block. When present and visible it gives every user an opportunity to browse all users participating in the current course.

Securing Moodle Data

This block is visible to any user that has the View participants capability enabled. This capability exists for system and course level. In Moodle 1.9.8 and later, by default this capability is enabled only for the Administrator role on both levels. That way no user other than Administrator will be able to see participants on the system level or in specific course.

If by any chance you use an older version of Moodle, then most likely you have this capability enabled on the course level for all standard roles except for guest and authenticated user. Unless you want to open privacy policy on your site we recommend you to disable this capability.

Visit the Administration Users | Permissions | Define roles| page, then locate and modify that capability by setting it to "Not set". Apply this at least on the Student role.

Securing Moodle Data

Forum topics

Forum topic offers another way of accessing the user profile. Regardless of the forum type, Moodle displays the author name for every post. This name is actually linked to the profile page for that user.

Securing Moodle Data

Messaging system

Moodle offers a messaging system for internal communications between users. The Messaging system can be accessed from three locations—personal profile page, platform front page, and course content page.

Moodle page



Profile page

Send message to any user capability is enabled


Front page

Message block is added by Administrator


Course content page

Message block is added to the course by Administrator or teacher


If any of these conditions are fulfilled users will be able to access the messaging system. By default none of these conditions are present for Students and therefore there is no danger of any privacy intrusion. However, it is a common practice in various installations of Moodle to add a messaging block to one or more courses. Any user will be able to communicate with other users within same context (course). The problem with messaging is that it enables any user to locate any other user registered in the platform. We can demonstrate this easily. Open the messaging dialog and switch to the Search tab. In the Name field enter one letter and press the Search button. You will get ALL user accounts that have the specified letter either in name or surname as a result.

Securing Moodle Data

The search result apart from the actual names of the users also offers a direct link to their personal profile.

Securing Moodle Data

This is a potentially dangerous feature that can expose more information than we are willing to permit. If messaging is called from a context in which the users have permission to view user profiles he will be able to see any profile in the system. This way user names and profiles are completely open. There is no way to modify this behavior (listing all users) other than disabling the messaging system. Having a messaging system enabled can be a problem if you have a malicious user within your system that wants to get names of all users or a spam-bot that wishes to harvest e-mail addresses. That is the reason we should do something about that.

Protecting user profile information

We have several options available for protecting access to private information located in personal user profile. You can choose one that is most appropriate for your particular use case.

Limit information exposed to all users

If we do not have a problem exposing some information of the user in their profile then we can then just hide some fields. To do that visit the Administration Users | Permissions | User policies| page and locate the Hide user fields section.

Securing Moodle Data

Using this approach you still cannot hide the user e-mail or his actual name which is good for cases where you want users to communicate with each other without knowing too many personal details.

Completely block ability to view profiles

If you want to completely block access to the user's profiles you have several options explained as follows:

Disable View participants capability

We already explained that by default every Moodle as of version 1.9.8 has this disabled by default. We are listing it here just for the sake of being complete.

Hide messaging system

Hiding messaging system means removing access points from user's reach. This means do not add Messages block on the front page and in any course where you wish to avoid users from knowing the other participants. This is useful where you want to have mixed messaging policy for different courses—set of users. Have in mind that this setup gives sort of a false sense of separation. Users from courses which do not have Messages block can still access Messaging system if they type the URL by hand.

Disable Messaging system

If you do not care for Messaging in your Moodle site you can completely disable it. To do that visit the Administration Security | Site policies| page and uncheck Enable messaging system option.

Not using general forums

If you have a website where you want to completely isolate only part of users within a course, among other things you can adopt the policy of not adding general forums inside such courses and on the site front page. That way you can still use forums in other courses where you do not have security concerns.

Disable View user profiles capability

If you want to completely block any possibility of viewing user profiles for specific role(s) you need to modify the View user profile capability and set it to "Not set". Visit the Administration Users | Permissions | Define roles| page, locate and modify that capability for every role you wish to prevent from viewing user profiles.

Securing Moodle Data

        Read more about this book      

(For more resources on Moodle, see here.)

Course information protection

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.

Course backups

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.

Important information for users of Moodle prior to 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.

Securing Moodle Data

Password hashes and salt

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 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:










If we go to the and try both hashes these are the results we will have, first for unsalted hash:

Securing Moodle Data

And then for salted hash:

Securing Moodle Data

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:

Enable password policy

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.

Enable password salt

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 Securing a Moodle Instance for details on how to enable password salt.

Disable teacher's ability to back up and restore courses

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.

Securing Moodle Data

Security issues with course backups

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.

Securing Moodle Data

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.

Securing Moodle Data

Scheduled backups

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.

Securing Moodle Data

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:\backupdata
icacls Z:\backupdata /Q /T /inheritance:r
icacls Z:\backupdata /Q /T /grant Administrators:(OI)(CI)(F)
icacls Z:\backupdata /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.


We exposed some security issues related to the user information within Moodle and ways to resolve them. We explained what user information is available within Moodle and ways for other users to access it, with a detailed section that explains how to close or limit those points if that is what we want. We also talked about pitfalls related to the backup and how to restore the courses, explained the importance of having a proper password policy, and configured password salt. After applying recommendations from this article your Moodle site will be much safer and will expose only the amount of information that you actually want.

Further resources on this subject:

You've been reading an excerpt of:

Moodle Security

Explore Title