-
New Feature
-
Resolution: Fixed
-
Minor
-
3.9
-
MOODLE_39_STABLE
-
MOODLE_39_STABLE
-
Most password checks have historically been deterministic, so you only really needed to check the check_password_policy on signup or when changing the password.
But there are two edge cases where it would be good to re-check the password on every single login:
1) if the password policy has changed and you want force people to quickly migrate to the new policy
2) a previous good password is now bad for non-deterministic reasons eg an external check.
Now that our password checking plugin which uses the https://haveibeenpwned.com/ API is live this is a perfect example of this:
https://github.com/catalyst/moodle-tool_passwordvalidator
In most cases if you are only using core checks, then the cost of performing them is very low. So there is no downside to having them always on. If you have gone to the trouble of installing a password checker like ours, then you are very likely to want this higher level of security.
So I am proposing to re-check check_password_policy very early on in the auth flow, and if it fails then flip the force password change bit and redirect them to the password reset page.
I'm on the fence around whether this should be an option and we have the ability to just warn people but let them in, or just force them to reset. Use cases for this are for things like 'I need to login to submit my assignment, oh I need to reset my password, oh my email isn't working for some reason'. For other plugins in similar positions we've implemented grace periods, but here in core I think it adds a lot of complexity in the config and code so I'm leaning towards a zero conf patch which forces a reset.
I think the logic flow is something like (this may be overkill)
If the password check fails
if can_reset_password() then don't login and redirect to reset page
if no reset but can_change_password() and change_password_url() is external then redirect to there
if no reset but can_change_password() and change_password_url() is internal then login and redirect to there
fall back to just output notification
- caused a regression
-
MDL-82719 Passwordless SSO auth plugins with $CFG->passwordpolicycheckonlogin outputs confusing notification to users
- Open
- has a non-specific relationship to
-
MDL-67950 Logical inconsistency between $CFG->passwordpolicy between check_password_policy vs print_password_policy
- Closed
-
MDL-68028 Improved $CFG->passwordpolicycheckonlogin with preference to reset vs change password
- Open
- has been marked as being related by
-
MDL-67977 Logical inconsistency between check_password_policy vs generate_password
- Open
-
MDL-66123 Add a user as an option argument to check_password_policy
- Closed
-
MDL-67912 Check passwordpolicychangeonfail in security report
- Open
-
MDL-61694 Create an extension point for adding extra password validation functionality
- Closed