The key to the security of your system lies in making sure that users only have access to their privileged areas in Moodle. In this section, we will be dealing with access to Moodle, passwords, security in roles, and spam prevention.
Users can access Moodle in different ways, and it is important to configure access mechanisms correctly. Some of those potential access risks are applicable in non-SSO settings.
Self-registration is a great feature, which, once set up, reduces the workload of the administrator significantly. However, it poses a potential risk that unwanted users are creating an account either manually or automatically. To reduce this risk, a number of settings are located in the Common settings section by going to Plugins | Authentication | Manage authentication:
These five settings have been described in detail in Chapter 5, User Management.
Moodle provides a feature, called guest access, to users who do not wish to register with a site (not to be confused with a guest user in a course). While this is very useful for some public sites (such as https://moodle.org/), it is unwanted in most educational and commercial settings. To deactivate guest access, go to the Common settings section and navigate to Plugins | Authentication | Manage authentication. Once there, change the Guest login button setting from Show to Hide.
A second setting that relates to guest access is can be seen by going to Users | Permissions | User Policies, where you will find the Auto-login guests checkbox. Turn this on only if you want visitors to log in automatically when they enter a course with guest access.
If you allow guest access as an authentication method, you can specify inside courses whether guest access is available as an enrolment mechanism, and you can also specify a guest access password. We dealt with this in Chapter 4, Course Management.
Identity theft is a common problem on the Internet, and Moodle is no exception. To avoid the possibility of fraudsters gathering details about authenticated users, a number of settings can be seen by navigating to Security | Site Policies:
Further down in the Site policies screen, you have the ability to activate Email change confirmation. If it's set to Yes, users will be sent an e-mail to confirm that their change of e-mail address in their profile is genuine.
When courses are displayed on the front page, users who are not logged on to the system will see a description and the names of the course managers of each course by clicking on it. By default, these are the teachers of the course. To change the names that are displayed for each course, go to Appearance | Courses, and select the roles to be displayed in Course contacts:
To hide the names completely, deselect all the roles. As a result, no names will appear when the course descriptions are shown.
Moodle offers a password policy feature that applies to manual accounts and which can be configured by going to Security | Site policies, as shown in the following screenshot:
The following self-explanatory constraints for passwords are available (default values are recommended as a minimum):
- Password length (≥
0) - Digits (
0…9) - Lowercase letters (
a…z) - Uppercase letters (
A…Z) - Non-alphanumeric characters (such as
$%&*) - Consecutive identical characters (≥
0) - Password rotation limit (the number of times before a user can reuse a password)
- Maximum time to validate password reset request (when password recovery is being triggered)
- Log out after password change (all browser sessions except the current one)
- Group enrolment key policy (this specifies whether the specified password policy rules should apply to a group enrolment key or not)
Password expiry can be specified for manual accounts (go to Plugins | Authentication | Manual accounts). We've already dealt with the three Enable password expiry, Password duration, and Notification threshold settings in Chapter 5, User Management. If you use an external authentication, for instance, an LDAP server, you will have to specify the expiry duration within the particular LDAP server(s).
You also have the option to lock out user accounts after too many failed logins. You can find the relevant settings by going to Security | Site policies. Account lockout threshold lets you specify the number of failed logins required to trigger a reactivation e-mail to the user. The Account lockout observation window setting lets you specify the period during which further failed logins will be included in the current suspension. Account lockout duration lets you specify the time after which the account will be unlocked automatically. Again, if you use an LDAP server for authentication, the lockout thresholds will be defined within the LDAP instance.
Most web browsers now offer a means to autocomplete passwords in a browser vault. While this is convenient for the end user, it also poses a security risk. If you wish to prevent browsers from autocompleting account passwords, select Prevent password autocompletion on login form by navigating to Security | HTTP security. Related to this setting is the option to remember usernames via cookies, which will then be entered in the login form when opened. You can configure the Remember username parameter by going to Security | Site policies.
Moodle stores passwords in an encrypted form using a so-called md5 hash. To improve the security of the passwords further, Moodle supports password salting, which adds a separate random string to the md5 hash of each user password.
Moodle used to apply a single site-wide salt to passwords, which was stored in the config.php file as $CFG->passwordsaltmain. If your site has been updated from an earlier version of Moodle (2.4 or lower), this salt will still exist and should be kept until you can ensure that every user is logged in to the site only once, which triggers a conversion to the safer scheme. You might consider forcing this via the Force password change option in Bulk user actions.
If you ever lose your admin password and have no means of recovering it, you are able to manually override the password field in the mdl_user table in the SQL database. Because the passwords stored are md5 hash encrypted, you will have to replace the current value with an encrypted password. For example, to set the password to newpassword, you need to use the following SQL statement:
UPDATE mdl_user
SET password = md5('newpassword')
WHERE username = 'admin';If your database does not support the md5 function, you will have to set password to the actual md5 hash tag. For example, this would be 5e9d11a14ad1c8dd77e98ef9b53fd1ba for newpassword. Use one of many available online generators to find out the tag.
The first time you log in to Moodle, the salt will be added and the new encrypted password will be stored in the database. More information on password salting in Moodle can be found at https://docs.moodle.org/en/Password_salting.
Moodle allows the creation of custom roles, such as Parent, Teaching Assistant, Secretary, Inspector, and Translator. However, the flexibility of this powerful mechanism comes with a price in the form of a potential security risk. On the other hand, one could argue that it also solves a potential security risk, for instance, by limiting the access of a teaching assistant, there is no need to not grant full teaching access.
Moodle displays the risks associated with each capability, that is, the risks that each capability can potentially raise. To recapitulate from Chapter 6, Managing Permissions—Roles and Capabilities, the five risk types are explained in the table that follows:
|
Risk |
Icon |
Description |
|---|---|---|
|
Configuration |
 |
Users can change the site configuration and behavior |
|
XSS |
 |
Users can add files and texts that allow cross-site scripting (potentially malicious scripts that are embedded in web pages and executed on the user's computer) |
|
Personal |
 |
Users can gain access to the private information of other users |
|
Spam |
 |
Users can send spam to site users or others |
|
Data loss |
 |
Users can destroy large amounts of content or information |
Because risks are only displayed to indicate what potential damage a capability can cause, you are responsible for the role definitions and contexts in which the roles are applied. Make use of the capability report and system permission checker, as we discussed in Chapter 6, Managing Permissions – Roles and Capabilities.
The Authenticated user role is assigned to everybody who is logged in to your site. It does not conflict with any other role and guarantees that certain operations can be carried out outside courses. Make sure that you don't change the scope of this role unless you really have to as any changes to this role will apply to every authenticated user on the system.
Default roles for different user types are assigned by navigating to Users | Permissions | User Policies. We dealt with these settings in detail in Chapter 6, Managing Permissions – Roles and Capabilities. Make sure that these settings are set correctly, especially for the guest and visitor-related roles.
If Moodle is not configured correctly, it allows spammers to insert content into user profiles of accounts that are created via self-registration. This type of attack is known as profile spam. To prevent this, make sure that the following settings are set correctly (which they are, by default):
- Only use e-mail-based self-registration if it is really necessary. No self-registration, no spam!
- Keep the Force users to login for profiles parameter enabled in your site policies (refer to the Protection of user details section). This way, you can prevent anonymous visitors and search engines from seeing user profiles.
- Make sure that the Profiles for enrolled user only parameter remains enabled.
Also, be aware that legit users can be the cause of spam. Make sure that no user has any unnecessary capabilities in their roles that allow for this (refer to spam risk in the Security in roles section). You might even consider the creation of a spammer role that allows access to activities, such as forums, but prevents content from being posted. You further have the option to limit access to changing profiles to only those users who are enrolled in a course via the Profiles for enrolled users only setting, which can be seen when you navigate to Security | Site policies.
If your site has been victim to spam, go to Reports | Spam cleaner. You can either let Moodle Autodetect common spam patterns (the list makes for some interesting reading!) or search for your own keywords:
Any user profiles where the Description field contains any of the listed keywords, are shown. You then have the option to delete the user account(s). For more information on spam prevention in Moodle, check out https://docs.moodle.org/en/Reducing_spam_in_Moodle.