|Read more about this book|
(For more resources on Moodle, see here.)
Basics of authentication
Authentication is the process of confirming that something or someone is really who they claim to be. The ways in which someone may be authenticated fall into three categories, based on what are known as the factors of authentication:
- Knowledge (something you know): password, PIN code, etc.
- Ownership (something you have): security token, phone, etc.
- Inherence (something you are): fingerprint, signature, various biometric identifiers
Following the path of most computer systems, Moodle offers basic authentication based on a knowledge factor. This means that in order to operate in Moodle any person must have a user account.
A user account consists of a username, password, and other personal information. Both username and password are used to authenticate a person who wishes to access the platform. Based on the outcome of an authentication, a user will be given or declined access to the platform. The authentication is performed (usually) by comparing provided data from the person trying to access the platform with the data located in the Authoritative Data Source (of user identity). Moodle supports 13 different types of authentication and this actually means that it has support for consulting 13 different types of Authoritative Data Sources.
An Authoritative Data Source is a recognized or official data production source with a designated mission statement or source/product to publish reliable and accurate data for subsequent use by users or by other computer programs.
Logon in Moodle is implemented using a HTML form that submits supplied data over HTTP or HTTPS to the server where it is being processed.
Hypertext Transfer Protocol (HTTP) is a networking protocol used for transferring and rendering content on the World Wide Web. HTTP Secure (HTTPS) is a combination of a HTTP protocol and SSL/TLS (Security Socket Layer/ Transport Layer Security) protocol that offers encrypted and thus secures communication and identification between two computers on the Internet. HTTPS connections are often used for payments transactions and other sensitive information's transfer.
The user enters his assigned credentials into the supplied fields on the login form and presses Login. That sends data to Moodle for processing.
Common authentication attacks
Any type of security attack is directed toward potential weak spots in the system that is under attack. The most common weaknesses related to the authentication and ways of protecting from them are as follows:
A password that is easily guessed and does not provide an effective defense against unauthorized access to a resource is considered weak. Such passwords are usually:
- Set to dictionary word or name
- Set to be the same as username
- Set to some predefined value
When we have a platform with weak passwords it can be attacked using brute force login technique (also known as dictionary attack).
Dictionary attack is a technique for defeating authentication mechanism by trying to determine its pass-phrase by searching likely possibilities. In practice this means that a bot (automated script) constantly tries to log on by sending various usernames and passwords from a predefined list of words (usually a dictionary list of words—hence the name dictionary attack).
Enforcing a good password policy
In order to prevent this attack, make sure you have enabled the password policy. Visit Administration | Security | Site policies and locate the Password Policy checkbox. You should arrive at the following screenshot:
Password policy is enabled by default starting from Moodle 1.9.7. This applies to both new installs and upgrades.
Protecting user logon
By default, Moodle is configured to use unencrypted HTTP as the main communication protocol between client and server. This is fine for general usage of the platform but it also exposes credential information to the potential eavesdropper who can intercept and read it. This is a common case known as man-in-the-middle attack. The perpetrator makes a separate connection with the client (user's computer) and server (Moodle), forcing all communication to go over his connection. That permits him to look at the entire communication and even inject his own version of messages and responses.
Closing the security breach
We need to make sure that credential transmission is performed using secure HTTP (HTTPS) because that prevents (or makes it really hard) for anybody to hook into a protected conversation. Here are the steps:
Firstly, you should install and configure a valid SSL (Secure Sockets Layer) certificate on your web-server. It is important to do this properly before doing anything else in Moodle; otherwise you might block yourself from accessing the platform. The procedure for installing an SSL certificate is beyond the scope of this book since it involves too many different factors that depend on your server configuration, OS type, and the way you manage it. Please refer to the manual for your particular web server and/or particular procedure of your hosting provider.
Valid SSL certificates can be obtained only from certified root authorities—companies with a license for issuing certificates. VeriSign, Thawte, and Comodo are one of the several certificate providers. You need to specify which web server you are using since some of them prefer particular formats.
Secondly, you should activate HTTPS log-in in your Moodle. You can do that by going to Administration | Security | HTTP security page and checking Use HTTPS for logins.
If everything is configured properly you should see a login page that shows a valid certificate box (see following screenshot) in your browser. This means that a certificate is issued by a valid root authority and that communication between your browser and Moodle is secure which is what we wanted to accomplish in the first place.
Every time a user tries to login in Moodle they will be redirected to the secure version of the login page which effectively prevents the interception of user credentials.
By default, all newly created users in Moodle (excluding admin) are assigned the Authenticated user role. The authenticated user role by default has permission to change their own password. This feature can be utilized by accessing user profile page.
Recover a forgotten password
Forgetting a username and/or password is a common situation in which many users find themselves. Moodle offers a procedure for getting a username and resetting the password.
The user will be presented with a form where he can enter his username or his e-mail. If the username or email exists in the database, a mail with a reset link will be sent to that user. By clicking on that link, the user is offered a chance to enter a new password.
If not configured properly, this feature can be used for determining valid user emails or user-names. See the following screenshot:
An attacker would be able to tailor a script that could probe for usernames and, based on the response, can determine valid users.
|Read more about this book|
(For more resources on Moodle, see here.)
Preventing a potential security risk
To protect from this potential flaw we need to disable error information from being displayed to the user. Go to the Administration | Security | Site policies page and make sure the Protect usernames option is activated.
After this change, Moodle displays a different message upon submitting username or mail.
If you want to completely disable this functionality you can do that by going to the Administration | Users | Authentication | Manage authentication and modify the value for Forgotten password URL. The quickest and easiest approach would be to specify the homepage of your Moodle platform as the new URL. In that case, if anybody wants to try and recover their password they will be redirected to the home page.
Disabling password recovery may generate an important impact on you as an administrator since all such requests would have to be handled manually.
Securing user profile fields
In Moodle, every user account has a profile. A profile is a set of information describing the user in more detail with information such as their address, ZIP code, telephone number, etc. Almost every authentication plugin has support for handling user profile fields. By default, in all cases a profile is open for user editing. Such configuration is correct when Moodle itself is the Authoritative Data Source (ADS) of user information. However, when we authenticate the user against external source, the situation is different. In such cases it is always better to lock profile fields or at least enable them only if they are empty. That way we maintain stable and predictable user information across all our systems. Only two plugins use Moodle as ADS and these are Manual accounts and Email-based-self-registration. The rest of the plugins synchronize against external sources.
User model in Moodle
Every user account in Moodle has four unique characteristics: username, password, e-mail, and authentication type. The username and e-mail must be unique on the system level and that prevents ambiguities in the platform. The authentication type determines which plugin will take care of credential validation. Bear in mind that Moodle can have more than one authentication plugin active. That is quite a common scenario in various installations. For example, administrative accounts are handled by the Manual accounts plugin while students and teachers can be handled by the LDAP plugin.
Authentication types in Moodle
One of the better features of Moodle as a platform is its diversity. Educational institutions often have a separate system(s) for handling students' information. Knowing that such a need exists, the Moodle community gradually added various types of authentication support.
We will now explain these in more detail and, where applicable, offer some advice on how to increase their security. The plugins presented here are just those that are the most widely used.
This is the default authentication plugin. It uses the Moodle database as a source of valid user credentials. Any user account created by the administrator is, by default, set to the Manual accounts type. The security measures mentioned in the first part of this article are adequate for this plugin. You do not need to do anything else if you plan on using just this plugin.
E-mail based self-registration
This plugin also uses the Moodle database as a source of valid user credentials. What is different is the way in which accounts are created. Here, users themselves can create their own account. Validation is performed through e-mail. This opens a possibility for spammers to create dummy accounts. To prevent robots and unwanted users to start polluting the site we have two options:
Specifying allowed or denied e-mail domains
In case all our users have e-mails in several predefined domains, then we can specify them in the authentication configuration and block any other unwanted e-mail account. This is an excellent way of preventing unwanted users to create an account in our Moodle. For example, if we notice that in last few days we had several hundred accounts created and all were using e-mails with domain evilhackers.net, then we can prevent them just by adding that domain to the Denied email domains. Visit the Administration | Users | Authentication | Manage authentication page and modify the setting according to your particular needs.
If you want to enforce mail domains restriction in case of changing existing user e-mail addresses, you need to check the appropriate option on the same page.
Captcha (Completely Automated Public Turing test to tell Computers and Humans Apart) is a challenge-response test used in logon protection to ensure that a response is generated by a human and not by a computer. It is usually implemented in the form of images with drastically distorted letters which are impossible to be deciphered by a computer.
A major problem any site with self-registering capability has is related to automated scripts (bots) that create a bulk of fake accounts usually used for generating spam. This problem is solved by Captcha.
Moodle supports the Google reCaptcha service. Google reCaptcha is a free Captcha service used to protect various online systems against automated logon. It does so by providing a user with a particular image with a couple of words that cannot be analyzed by a computer but are readable to a human. By providing a valid sentence, the user is validated as a human and thus permitted to enter.
You should open a Google account and register for reCaptcha. For this you should visit http://www.google.com/recaptcha to register and generate API keys for your platform. The registration procedure is quite straightforward. Just follow the onscreen instructions provided by Google. After you obtain the keys place them on the "Manage Authentication" page. To open that page visit Administration | Users | Authentication | Manage authentication.
When the user tries to apply for a new account he will be presented with something like this:
Session hijacking is the exploitation of a valid computer session, sometimes also called a session key to gain unauthorized access to information or services in a computer system. This basically means stealing the magic logon hash from the session cookie.
The most common techniques used for hijacking user session are as follows:
- Session sniffing: Communication between client and server is being monitored by a third party. During this interaction the third party can pick up session ID and then use it to directly access server without the need to log in.
We have several options offered by Moodle in treating this exploit. On the HTTP security page these options are available:
- Only http cookies: This is a new feature available as of PHP 5.2. This means that cookie information is being transferred only through HTTP requests without any access given to the scripting languages. If you use the latest version of PHP and do not have to support legacy web browsers this option is highly recommended.
- Regenerate session during login: Creates new session for every login. This is highly recommended for security reasons. It can bring some problems with shared sessions and with some authentication plugins. In general, it works well with manual accounts and self-enrolled accounts. It can also exhibit issues with the users that often change IP (switching from one wireless network to another).
This plugin is used to disable a particular user account. To do that, go to Administration | Users | Accounts | Browse list of users and locate the user you wish to prevent from logging in and click on the Edit link.
After that, click on the Show Advanced button and modify the Choose an authentication method field.
In this article we learned a lot about the Moodle user model. Major security holes in the logon process were covered, along with ways of closing them. You learned about session hijacking, dictionary attack, and ways of fighting against them. We mentioned the most commonly used types of authentication. A clear and exact procedure of configuring and securing those plugins was presented. The final outcome of all this is a much more secure logon/authentication procedure.
- Integrating Moodle 2.0 with Alfresco to Manage Content for Business [Article]
- Integrating Moodle 2.0 with Mahara and GoogleDocs for Business [Article]
- What's New in Moodle 2.0 [Article]
- New Modules for Moodle 2 [Article]
- Securing a Moodle Instance [Article]
- Introduction to Moodle Modules [Article]
- History Teaching with Moodle [Book]
- Moodle 1.9 Top Extensions Cookbook [Book]