Users authentication failure

Users authentication failure

by Aida GP -
Number of replies: 2

Hi everyone!

We are using Moodle 3.9+ with Classic theme and this week we are facing with an issue during the users’ login.

In particular, some users are not more able to login even if the credentials (username and password) are valid.


We are analyzing the problem and it seems that the problem is due to the hash algorithm used for storing the passwords.

Following the use case:

  1. If the hash algorithm for the stored password is $2y$04, the user cannot login and he has to change the password (even if the password is still valid).
  2. If the hash algorithm for the stored password is $2y$10, the user correctly logs in.
  3. For the new user, there is not that problem. The user is able to change the default password (we force the password change at the first access) and the user correctly logs in.


We are not setting the type of hash algorithm to be used by Moodle for the password storage and it seems that the chosen algorithm is random.


Does someone know if recently some Moodle settings are changed related to the authentication?

How is it possible to avoid and permanently solve that problem?


Thank you for your help!


Average of ratings: -
In reply to Aida GP

Re: Users authentication failure

by Leon Stringer -
Picture of Core developers Picture of Particularly helpful Moodlers

Has there been any recent upgrade of Moodle or PHP? Or any server migration? If so, is there a $CFG->passwordsaltmain value in config.php that wasn't migrated?

Average of ratings: -
In reply to Leon Stringer

Ri: Re: Users authentication failure

by Aida GP -
Hello,
Sorry for the delay in answering.
No upgrade, no change in configuration lately.
The issue is observed only for accounts which in the past had the password hashed with fasthash, i.e. only 04 iterations and the system did not upgrade as it should do by default to 10 iterations when the user changes the password.
The users which force-change the password these days have the hash correctly upgraded to 10. Why in the past this did not happen and they still have 04 after password change? Why now the system doesn't know to check the password hashed with 04 as it is correctly in the database, for the users which had change their password in time? It does only for new users, since end of March 2022, who have force-password-change flag and the new hash is done in background without any impact to the user experience.
So for us the only solution is to ask the users to do Forgot password.
Thank you
Average of ratings: -