Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-66123

Add a user as an option argument to check_password_policy

XMLWordPrintable

    • MOODLE_37_STABLE
    • MOODLE_38_STABLE
    • mdl_66123
    • Hide

      Requirements

      • Either an SMTP server configured, or mailcatcher/mailhog configured.

      Testing instructions

      To test this change, all of the touch points for the function can be visited, and password validation can be run.

      1)  Login as admin and visit the Site Security settings at Site Administration->Security->Site Security Settings. Set the control 'Password Policy' to off. This ensures the only validation will be from the plugin we will install, which will always fail. This helps with the visibility of the responses, ensuring it is easily seen. 

      2) Before testing the functionality of the changed core function, create a new dummy account to use to test functionality where actions another account are required. On the moodle instance, visit Site Administration->Users->Accounts->Add a New User.

      Create a new user with data:

      • Username: testuser
      • First Name: Test
      • Surname: User
      • Email: test@user.org
      • Password: password

      The best way to test these validation points is to install a plugin, that makes use of the changed callback function. A small plugin to test this tracker has been developed, that simply fails validation by returning the username of any $user object passed to it, so the username will be displayed to the user, and it can be easily verified the correct account is being supplied in the plugin call.

      3) To install the plugin, navigate to the moodle main directory, open a terminal, and use git to clone the plugin from GitHub:

      git clone https://github.com/Peterburnett/MDL-66123_tester.git admin/tool/passwordchangetester
      

      4) Once the plugin has been cloned, visit the main admin page to ensure that the install plugin script runs.

      5) login/change_password_form.php is accessible by visiting User Profile->Change Password. Attempt to change the password to anything, such as '123'. The verification will return the username of the account that you are currently changing the password of, typically the logged in account.

      6) login/set_password_form.php is accessible by logging out, and submitting a password reset request for an account that has an active email address, such as the admin account. Follow the emailed URL, and this page is displayed. Attempt to set a new password, such as '123'. The verification will return the username of the account whos' password you are attempting to set.

      7) lib/authlib.php is accessible by creating a new account on the moodle instance and attempting to set a password on the account. Ensure that users have a way to self-sign up, such as email-based self signup, by visiting Site Administration->Plugins->Authentication->Manage Authentication and set the control 'Self Registration' to Email-based self-registration.

      Now log out of the moodle instance, and visit the login page. Click "Create new account" at the bottom, and then proceed to create a new account using dummy data, with the username 'testuser2', and then attempt to set a password. The validation will return the username 'testuser2'.

      8) /user/editadvanced_form.php is accessible by visiting Site Administration->Users->Accounts->Add a new user. This form allows admin accounts to create new users. Fill in the form with dummy data, with the username 'testuser3', and attempt to set a password. Click 'Create User', and verify that the validation fails, and returns the username of the account that is attempting to be created.

      9) /user/lib.php is accessible in the same way as above. Once the validator on advanced form passes, user/editadvanced calls user/lib.php to add or update user details, and the validation is performed a second time, therefore no additional testing needs to be performed here.

      10) admin/tool/userupload/index.php  To test this, download the CSV file 'Tester CSV.csv' attached to this tracker. Visit Site Administration->Users->Accounts->Upload users, and upload the downloaded CSV file. Click on 'Upload Users' to proceed to the next step.

      Ensure that the options are:

      • Upload type: Add new and update existing users.
      • New user password: Field required in file.
      • Existing user details: Override with file.
      • Existing user password: Update.
      • Force password change: All.

      These settings will force the password validation to be run. Click 'Upload Users'.

      This page does not display return messages from the check_password_policy, but it can be verified by checking that the section 'Users having a weak password:' is 1. it will also display 'Invalid Password Policy' underneath passwords on the uploaded account. It can be verified that this is caused by the plugin, as the password policy in disabled above.

      11) admin/cli/reset_password.php To test this CLI script, simply navigate to the moodle base directory, open a terminal window at that location, and run:

      php admin/cli/reset_password.php
      

      Set the to any user account, such as 'testuser', and any password, such as '123' and verify that the script returns the username of the account entered.

      Show
      Requirements Either an SMTP server configured, or mailcatcher/mailhog configured. Testing instructions To test this change, all of the touch points for the function can be visited, and password validation can be run. 1)   Login as admin and visit the Site Security settings at Site Administration->Security->Site Security Settings. Set the control 'Password Policy' to off. This ensures the only validation will be from the plugin we will install, which will always fail. This helps with the visibility of the responses, ensuring it is easily seen.  2) Before testing the functionality of the changed core function, create a new dummy account to use to test functionality where actions another account are required. On the moodle instance, visit Site Administration->Users->Accounts->Add a New User. Create a new user with data: Username: testuser First Name: Test Surname: User Email: test@user.org Password: password The best way to test these validation points is to install a plugin, that makes use of the changed callback function. A small plugin to test this tracker has been developed, that simply fails validation by returning the username of any $user object passed to it, so the username will be displayed to the user, and it can be easily verified the correct account is being supplied in the plugin call. 3) To install the plugin, navigate to the moodle main directory, open a terminal, and use git to clone the plugin from GitHub: git clone https: //github.com/Peterburnett/MDL-66123_tester.git admin/tool/passwordchangetester 4) Once the plugin has been cloned, visit the main admin page to ensure that the install plugin script runs. 5) login/change_password_form.php is accessible by visiting User Profile->Change Password. Attempt to change the password to anything, such as '123'. The verification will return the username of the account that you are currently changing the password of, typically the logged in account. 6) login/set_password_form.php is accessible by logging out, and submitting a password reset request for an account that has an active email address, such as the admin account. Follow the emailed URL, and this page is displayed. Attempt to set a new password, such as '123'. The verification will return the username of the account whos' password you are attempting to set. 7) lib/authlib.php is accessible by creating a new account on the moodle instance and attempting to set a password on the account. Ensure that users have a way to self-sign up, such as email-based self signup, by visiting Site Administration->Plugins->Authentication->Manage Authentication and set the control 'Self Registration' to Email-based self-registration. Now log out of the moodle instance, and visit the login page. Click "Create new account" at the bottom, and then proceed to create a new account using dummy data, with the username 'testuser2', and then attempt to set a password. The validation will return the username 'testuser2'. 8) /user/editadvanced_form.php is accessible by visiting Site Administration->Users->Accounts->Add a new user. This form allows admin accounts to create new users. Fill in the form with dummy data, with the username 'testuser3', and attempt to set a password. Click 'Create User', and verify that the validation fails, and returns the username of the account that is attempting to be created. 9) /user/lib.php is accessible in the same way as above. Once the validator on advanced form passes, user/editadvanced calls user/lib.php to add or update user details, and the validation is performed a second time, therefore no additional testing needs to be performed here. 10) admin/tool/userupload/index.php   To test this, download the CSV file 'Tester CSV.csv' attached to this tracker. Visit Site Administration->Users->Accounts->Upload users, and upload the downloaded CSV file. Click on 'Upload Users' to proceed to the next step. Ensure that the options are: Upload type: Add new and update existing users. New user password: Field required in file. Existing user details: Override with file. Existing user password: Update. Force password change: All. These settings will force the password validation to be run. Click 'Upload Users'. This page does not display return messages from the check_password_policy, but it can be verified by checking that the section 'Users having a weak password:' is 1. it will also display 'Invalid Password Policy' underneath passwords on the uploaded account. It can be verified that this is caused by the plugin, as the password policy in disabled above. 11) admin/cli/reset_password.php  To test this CLI script, simply navigate to the moodle base directory, open a terminal window at that location, and run: php admin/cli/reset_password.php Set the to any user account, such as 'testuser', and any password, such as '123' and verify that the script returns the username of the account entered.

      Lots of security policies are specific to a user. eg

      • has this user used this password before
      • does the password contain their own name or date of birth

      Proposal:

      1) check_password_policy accepts an optional user. If the user is empty assume there is no user, ie don't assume $USER

      2) mirror this in the xyz_check_password_policy callbacks

      3) Everywhere in core should work with an explicit user object, potentially a partially formed one during the signup process

       

            peterburnett Peter Burnett
            brendanheywood Brendan Heywood
            Nathan Nguyen Nathan Nguyen
            Sara Arjona (@sarjona) Sara Arjona (@sarjona)
            Janelle Barcega Janelle Barcega
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved:

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 2 hours, 30 minutes
                2h 30m

                  Error rendering 'clockify-timesheets-time-tracking-reports:timer-sidebar'. Please contact your Jira administrators.