Moodle plugins directory: Reset Password | Moodle.org
Reset Password
This local plugin allows an external service to access moodles reset password functionality.
By posting a secure key, along with the user accounts email address, the local plugin will check against certain criteria before loggin, and sending the moodle password reset email.
The plugin checks a series of events before allowing the password reset email to be sent.
1 - Checks the plugin has been enabled (plugin setting disabled by default)
2 - Checks the encrypted key from the POST message matches the one stored in moodle (plugin setting)
3 - Checks the user exists in the moodle user table
4 - Checks the user is not an admin (admins have been restricted from using this plugin for security reasons)
The plugin works by an external service sendding a POST request to the following plugin file
[YOUR MOODLE URL] / local / resetpassword / reset.php
eg moodle.example.com/local/resetpassword/reset.php
The file requires two variables to be posted to it.
e - the email address of the account
k - the encrypted key
The encrypted key that is posted to the file is created by concatenation of the email address and the private key (set in moodle), this is then encrypted with MD5.
Screenshots
After reading your plugin's description, I expected to see it providing a new web service function - as described at
http://docs.moodle.org/dev/Web_services and http://docs.moodle.org/dev/Adding_a_web_service_to_a_plugin Was there any reason for not
doing it that way? Your solution looks and feels like re-inventing the wheel, to be honest. If it was proper web service, admins
would have much greater control over it. It would also provide extra protection - such as limiting the caller's IP etc. Based on my
personal experience, I really recommend you to consider this change yet.
I do not think that the MD5 hash provides any extra security here. MD5 is known to be pretty weak hash, especially if big chunk of
the message is already known (such as the e-mail address here). Also note, e-mail is generally not a unique identifier on sites with
MNet enabled. You should consider improving your current getUserId() function to take that into account (basically, it should find
only user records with mnethostid equal to $CFG->mnet_localhost_id. Please grep the Moodle core code for examples of similar
queries.
On contrary to what the screen-shot shows, the default value for the private key seems to be hard-coded for the integer value "10".
Please look at the is_siteadmin() core function and consider using that instead of the capability check.
I noticed that you create functions in the global PHP scope without the valid frankenstyle prefix. This is strongly discouraged in
order to prevent collisions with (current and/or future) core code or some other plugin. See
http://docs.moodle.org/dev/Coding_style#Functions_and_Methods for details.
I believe the PHP docs block comment in the file lang/en/local_resetpassword.php was left after copy-pasting from another plugin.
It is encouraged to follow Moodle’s coding style as outlined in: http://docs.moodle.org/dev/Coding_style and
http://docs.moodle.org/dev/Coding The code checker plugin can be quite helpful in fine tuning your code and can be found at:
https://moodle.org/plugins/view.php?plugin=local_codechecker You may wish to consider using that tool to further improve your
plugin's style (such as using camelCase for function names).
Please note that the organisation of your plugin repository at Github does not allow folks to clone it directly into their Moodle tree.
We suggest that in order to facilitate contributions to your code.
For now, I am going to mark this plugin as needing more work until we get these issues resolved. Thanks for your patience with the
review and approval process.
Thanks for your input on this plugin! Great to get a second opinion on it, and see where I have gone wrong.
My original plan, as stated here,
https://moodle.org/mod/forum/discuss.php?d=260912
was to implement this functionality into a client specific web-services plugin I have already created. Originally we where completing this in a rather unfashionable way where we would curl the HTML of the /login/forgot_password.php page and regex out the session key, so we could send the correct post back to the same page as if the user was using the website.
Obviously a horrible implementation, and was never going to be used on the live production site. I then went to post to the developers forum as above, asking for a good way to implement this properly. I had considered adding it to the web-services plugin I have already created, but for that to work, the user would already have to be authenticated so I could use their private key. This defying the point of the whole objective as the user in my scenario will not yet be authenticated.
I did some research and could not seem to find a way to implement the web-service without the user being authenticated. So after the advice of Darko Miletić I made a local plugin to service these requests.
In regard to the MD5 sum, I do agree it is not the strongest hash, and is easily crack-able when most of the original string is given. But in this case, I had added it to stop people from easily being able to spam POST requests to send out reset password emails. Maybe in hindsight I could put a minimum string length on the privateKey variable to more than 20 chars, and wrap the email in this private key instead of just adding it, maybe implement sha5 instead or so on.
Thanks for pointing out the default value of the setting. I had changed this in a later version but did not re-upload the code to this page.
If you have any further input on a different route in which I can turn this plugin into a web-service without the user-authentication then I will be happy to follow that route, and add it to my existing webservices plugin. Otherwise I will make the required changes to this plugin and have it resubmitted for review again.
Thank-you again for looking through this plugin. Always open to suggestions and input from others in the community
Regards
Aaron
app user to authenticate successfully at least once prior being able to use the Lost password button. And the server side setup
would be more complicated as the user would have to create a dedicated web service user account for this password reset (this
user's token would then be stored in the app after the first successful authentication). But it just smells for no real benefit.
OK, it makes sense now. Let us aim on fixing all other issues then. Thanks for clarifying the situation. I can imagine that you
will want to add some locking after certain number of failed hashes provided, to prevent brute force attacks. But that can wait
for future version, no need to insist on it at this stage I think.