The current method that Moodle uses to authenticate to external web pages has serious shortcomings. For instance, one of the methods is to send the md5 hash of the user password as a GET parameter in the url. This easily lends itself to replay attacks on the target web site and to dictionary password attacks on the Moodle web site.
For instance suppose somebody logged into Moodle in a public computer lab clicks on such a link. Subsequent users of that computer could easily find the md5 hash of the previous user's Moodle password in the browser history cache. This would enable those users to gain unauthorized access to the target web site of the link. It would also enable those users to mount a dictionary attack on the md5 hashed Moodle password with a fair chance of success. If they succeed, they can log into the Moodle site.
A much better way of authenticating would be to concatenate the user password md5 hash with the other parameters and then take the md5 hash of this concatenated string. Alternatively the data could be hashed with a teacher supplied pass phrase or an administrator supplied pass phrase. The administrator supllied pass phrases should be stored in some separate configuration file, say accessCodes.php having the following structure:
$accesscode['http://www.example.com/blah/blah'] = "Pass phrase 1";
$accesscode['http://www.topsecret.org/blech/blech'] = "Pass phrase 2";
I attach below a picture of the setup for such authentication.
Also Moodle should have the ability to be the target of such web links from other Moodle sites.
In reply to Zbigniew Fiedorowicz
Re: Security problems with web link authentication
by Martin Dougiamas -
I think you have misunderstood how this actually works - not surprising since I don't think it's mentioned in the help files yet.
Firstly, don't pass the user password by itself!
Use the parameter "encryptedcode". It is constructed using a secret phrase that the admin sets in Admin >> Config >> Modules >> Resource >> Settings. It's not susceptible to a replay attack because it also uses the user's IP.
$encrytedcode = md5($_SERVER['REMOTE_ADDR'].$CFG->resource_secretphrase));
Firstly, don't pass the user password by itself!
Use the parameter "encryptedcode". It is constructed using a secret phrase that the admin sets in Admin >> Config >> Modules >> Resource >> Settings. It's not susceptible to a replay attack because it also uses the user's IP.
$encrytedcode = md5($_SERVER['REMOTE_ADDR'].$CFG->resource_secretphrase));
In reply to Martin Dougiamas
Re: Security problems with web link authentication
by Zbigniew Fiedorowicz -
In the scenario I outlined above, this wouldn't help since the second user would be using the same public computer as the first one and hence would have the same IP address. Moreover sending the password, even though hashed, in this way is a bad idea. It is like allowing random people to have a peek at /etc/password(shadow), perhaps even worse because no salt is used in the hash. A much better way is to indirectly prove you know the password by hashing it with some variable data.
Also the single pass phrase is too inflexible. It should be an array indexed by resource urls.
What I have in mind is a first step in the direction of this discussion:
http://moodle.org/mod/forum/discuss.php?d=6487
Also the single pass phrase is too inflexible. It should be an array indexed by resource urls.
What I have in mind is a first step in the direction of this discussion:
http://moodle.org/mod/forum/discuss.php?d=6487
In reply to Zbigniew Fiedorowicz
Re: Security problems with web link authentication
by Zbigniew Fiedorowicz -
Also I believe that people using dynamically assigned proxies (AOL?) might have trouble with the current scheme. Their apparent IP address might change, since a different proxy might be used to access the target link. [I think one scheme for dynamically assigning proxies is based on the IP range of the accessed web site.]
In reply to Zbigniew Fiedorowicz
Re: Security problems with web link authentication
by Martin Dougiamas -
The problem with including the password into the hash is that actually implementing a resource link to another arbitrary system becomes too difficult for an average admin. Using the IP and a single secret phrase is simple enough that adding the security code to nearly any external system is just something like this:
if ($_GET['encryptedcode'] != md5($_SERVER['REMOTE_ADDR'].$secretphrase)) {
echo "Access denied";
die;
}
I think it's "good enough" for most situations, especially since the chance of a rather desperate cracker being able to use the same computer right after their target is usually very remote. Another simple check you could add on the remote system is a check on the referrer URL. Or a script that randomly changes the secret phrase on both systems every ten minutes.
However, I do take your point for sure that it could be done a lot more securely for situations where greater information is available, such as a Moodle-to-Moodle case where both are authenticating from the same source. For this I think we should add a second encrypted code to the list of options in the Resource module, perhaps along the lines you suggest.
if ($_GET['encryptedcode'] != md5($_SERVER['REMOTE_ADDR'].$secretphrase)) {
echo "Access denied";
die;
}
I think it's "good enough" for most situations, especially since the chance of a rather desperate cracker being able to use the same computer right after their target is usually very remote. Another simple check you could add on the remote system is a check on the referrer URL. Or a script that randomly changes the secret phrase on both systems every ten minutes.
However, I do take your point for sure that it could be done a lot more securely for situations where greater information is available, such as a Moodle-to-Moodle case where both are authenticating from the same source. For this I think we should add a second encrypted code to the list of options in the Resource module, perhaps along the lines you suggest.