Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Password Reset Proposal: Difference between revisions

From MoodleDocs
No edit summary
No edit summary
Line 33: Line 33:
* Doesn't send the user any passwords which they don't end up keeping
* Doesn't send the user any passwords which they don't end up keeping
* Doesn't require the user to copy and paste at any stage.
* Doesn't require the user to copy and paste at any stage.
* Is fast
* Secure
* Aligns well with other site's password reset routines.

Revision as of 09:26, 18 July 2013

The password reset process in Moodle is longer and more invloved than it needs to be.

Currently there are 14 steps in the standard password reset process. Step 1 is the user clicking the link on the login page, step 2 is the system displaying the password-reset-request form, step3 the user enters their identifier ..... right through to the user being logged in (14).

I think we can reduce this to 8 steps; improving usability without comprimising security.


In both the existing, and proposed solutions, the user starts with the above steps 1-3, but the processes diverge at step 4, before re-converging at the last step ("User Logged in").


Processes side-by-side, step 4 to completion:

Current process Proposed process
passwordresetpresent.png passwordresetnew.png

As I see it the essential steps for password resetting are:

  • Establish who the resetting user (resetter) claims to be (the target user account)
  • Verify that the resetter has access to the target user account's email inbox
  • Obtain acceptable new password from resetter

The proposed process ticks of all these items.

A few extra details: In the proposed reset process, Moodle stores a record of the password resets requested, the one-time token that resulted. The email sent to the user will contain a link to the password setting page. When the user posts the form containing the two copies of the new password, along with the original token, the password is updated, the token deleted, and the user is logged in. There will need to be an admin setting to specify how long to allow for the email sending - (30 min default), and a job to delete tokens that are significantly out of date.

Advantages of the new process are:

  • Only requires one email step
  • Doesn't send the user any passwords which they don't end up keeping
  • Doesn't require the user to copy and paste at any stage.
  • Is fast
  • Secure
  • Aligns well with other site's password reset routines.