Earlier today I had bulk uploaded a group of users with a generic password. I'm not sure if it is possible during the bulk upload to force a password change (I suspect it is) but I did not do it. As a result, I had to go in and manually change these. Thankfully there were not that many but it did get me thinking that it would be nice if there were an option under bulk user actions. So I created a feature request for Moodle 1.9 (MDL-13557). I figured that it should not be too difficult to do so I went ahead and wrote up a patch that should handle it. If you think this might be useful or helpful to you, please feel free to vote on it. Peace - Anthony
Thanks Anthony for your proposal and patch 
To answer your question, it's writen in Upload User documentation that you just have to put "changeme" as password to force the fact that it must be changed
Séverin
To answer your question, it's writen in Upload User documentation that you just have to put "changeme" as password to force the fact that it must be changed
Séverin
Séverin - Thanks for following up on the changeme password. I had forgotten about that option. I think it would be an improvement if we were able to set the password to something else initially and also tag it as requiring to be changed. I think that would reduce the risk of a user account being hijacked. Which reminds that I should double check to ensure that the password validation checks are being enforced during imports. Peace - Anthony
I'm ok with you : the "user must change password" option must be active, even if he hasn't "changeme" as password (and it's like that)
Séverin
Séverin
Which reminds that I should double check to ensure that the password validation checks are being enforced during imports.
I doesn't seem so in 1.9 current as of today. It simply calls hash_internal_user_password() with the new password, and that's it.
We should call check_password_policy() at some point, but I don't know which is the most sensible place for the check (I don't master the new code after the big refactor).
Saludos. Iñaki.
Iñaki - I think that if we make the check_password_policy part of the if condition before doing the hash_internal_user_password that would work. In other word something like:
if ($value !== '' and (check_password_policy($value) or $value='changeme')) {
means that if they have supplied a password and it either meets the complexity requirements or they are using changeme to force the user to change the password on first login then go ahead and set the password. I've created MDL-14092 to address this issue and listed it as a minor security issue since it could be used to circumvent the password requirements.
Personally though, as mentioned above, if password complexity is in place, I would like to see the ability to set a password - perhaps even one based on a %f%l type template - that meets the password complexity. I think being able to add the idnumber to the templates as %i would make it even more powerful as a student id which some schools keep as private or encourage students to keep reasonably secure could be used to make a fairly complex initial password. For example if we have student John Doe with a student id number of 12345 we could generate a password of doeJ#12345 (%-l%+1f#%i).
Continuing to think out loud, it would be interesting that if the password requirements were set that upon logging in, if the password did not meet the requirements that the user were forced to change it. But that may be another issue for the tracker that we can conquer later.
Peace - Anthony
if ($value !== '' and (check_password_policy($value) or $value='changeme')) {
means that if they have supplied a password and it either meets the complexity requirements or they are using changeme to force the user to change the password on first login then go ahead and set the password. I've created MDL-14092 to address this issue and listed it as a minor security issue since it could be used to circumvent the password requirements.
Personally though, as mentioned above, if password complexity is in place, I would like to see the ability to set a password - perhaps even one based on a %f%l type template - that meets the password complexity. I think being able to add the idnumber to the templates as %i would make it even more powerful as a student id which some schools keep as private or encourage students to keep reasonably secure could be used to make a fairly complex initial password. For example if we have student John Doe with a student id number of 12345 we could generate a password of doeJ#12345 (%-l%+1f#%i).
Continuing to think out loud, it would be interesting that if the password requirements were set that upon logging in, if the password did not meet the requirements that the user were forced to change it. But that may be another issue for the tracker that we can conquer later.
Peace - Anthony
Personally though, as mentioned above, if password complexity is in place, I would like to see the ability to set a password - perhaps even one based on a %f%l type template - that meets the password complexity.
The problem with this approach (in addition to the code complexity sorrounding the template processing and error handling) is that you cannot guarantee that the generated password complies with the policy, unless you specify a way for the template to signal 'lowercase this part' or 'uppercase this part'. If you don't have this, you need to relay on certain fields (surname, first name, etc.) having a particular case. I'd say this is not robust enough.
On the other hand, with the new generate_password() going in in short (see MDL-14104), we can simply use it to generate a random password that meets all the configured password complexity settings. This has a drawback: we no longer know the new user password, so we can't tell her/him.
But we can specify 'changeme' as the password in the CSV file and, if we have a password policy in place, handle it a special way. We do the check you proposed above and later on, once we have updated or created the user, we set the 'auth_forcepasswordchange' flag for that user (to force a password change upon next logon) and call reset_password_and_mail(). This function creates a new random password (by calling generate_password()) and then mails the user with the password details.
What do you think of it?
Saludos. Iñaki.
Iñaki - I got the idea for the template from the help file uploadusers2.html which does allow for case to specified with + and - signs. The only suggestion I would have is to add the idnumber to list of fields recognized by the template. Since the code already exists to process the template I was hoping we could reuse it. I am OK with the generate new password approach and like the code I saw that you were proposing to ensure that the generated password complies with the complexity requirements. If I get some time (which is not likely but nevertheless if I do) I will try to generate a patch that makes use of the template. In the meantime, I would say lets keep moving forward with the other issues and see if we can get some of the work put into 1.9.1 and then continue to improve it. Peace - Anthony
Anthony, having a look at MDL-13557 I see you mention key logging and password stealing as one of the reasons for the forced password change.
But I think in this particular situation a password reset is a much better option. I mean, if an attacker has stolen a victim's password and you force a password change, the attacker might try to login before the victim does, so the attacker will have the opportunity to set a new (temporay) password and then reset it back to the original one (so the victim doesn't notice the password change at all).
On the other hand, if you were able to bulk reset passwords, this kind of attack would not be possible. Password reset emails the new password to the victim (and ideally we would force a password change upon next login), so unless the attacker has also access to the victim's email, he won't be able to use the victims account any more (provided the keyloggers are removed, etc.).
So maybe two different options are in order here:
- bulk force password change
- bulk password reset
If the password reset is augmented with the suggestion you make in http://moodle.org/mod/forum/discuss.php?d=93569 that would provide a more robust solution, don't you think?
Saludos. Iñaki.
Iñaki - Yes, I agree two separate options would make more sense and be more powerful for the administrator. I was simply trying to make a case for a potential use of the force password change but yesterday began to realize the importance of setting a password and a bulk password reset would also be great according to a certain pattern. Used together I think that admins around the world might sleep better Peace - Anthony
Edit the file \admin\uploaduser.php and add the lines in red at the location you can see here. Best way is to search for $usersnew++ and then copy/paste these new lines into the script.
Hi everyone,
I was just looking through the file uploaduser.php if you look closely, there is a concept of a week password here (which is determined by the function check_password_policy). It looks like if you give a week password while uploading bulk users it moodle forces users to change password when they login for the 1st time. The below code enables this;
if (!empty($CFG->passwordpolicy) and !check_password_policy($value, $errmsg)) {
$forcechangepassword = true;
$weakpasswords++;
}
So i guess our best bet is to give a week password initially which will help overcome the hacking problem too.
HTH
Neelima
I was just looking through the file uploaduser.php if you look closely, there is a concept of a week password here (which is determined by the function check_password_policy). It looks like if you give a week password while uploading bulk users it moodle forces users to change password when they login for the 1st time. The below code enables this;
if (!empty($CFG->passwordpolicy) and !check_password_policy($value, $errmsg)) {
$forcechangepassword = true;
$weakpasswords++;
}
So i guess our best bet is to give a week password initially which will help overcome the hacking problem too.
HTH
Neelima