Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
By default, if you force the user to change their password, it's possible for them to log in with their old password, be re-directed to the account page and change their password there. The problem with this approach, especially in light of Heartbleed, is that if someone was able to get the user's password, they could then use that to reset the password to something they want and gain access to the account.
The only way to prevent this is to force the user to be logged out and then only allow them to reset their password using the built-in password reset form at user/password.
Patch incoming...
Comments
Comment #1
anemirovsky CreditAttribution: anemirovsky commentedThe attached patch adds an option to force the user to be logged out if they have been forced to reset their password.
Comment #2
AohRveTPV CreditAttribution: AohRveTPV commentedI agree and have had the same concern with the force password change feature. Ordinarily new features should go in 7.x-2.x first, but I think this warrants an exception since it fixes a security deficiency.
The setting implemented in the patch could be a bit confusing to administrators: An administrator might check the "Force password change at next login" checkbox on a user's page, but if the new setting is set, the password change would actually be forced before, not at, the next login. (That the user is technically logged in and immediately logged out is an implementation detail.)
It would add clarity, I think, to change the text of that field depending on how your new setting is set. In the case that your setting is set, it could be:
Label: "Force password change before next login"
Description: "The user will be logged out if currently logged in."
What do you think?
Also, I think a
variable_del()
is needed inhook_uninstall()
implementation.Comment #3
anemirovsky CreditAttribution: anemirovsky commentedThe attached patch includes the changes you requested. Let me know if there's anything else that needs tweaking.
Comment #4
AohRveTPV CreditAttribution: AohRveTPV commentedThanks, I will plan to try it out soon.
I am wondering if this behavior should become the default for forced password changes.
We should probably add some SimpleTest testing of this new functionality.
Comment #5
AohRveTPV CreditAttribution: AohRveTPV commentedA problem is the combination of this new setting and "Force password change on first-time login". If both are enabled, the user is required to use the password-reset form to change their password before their first allowed login, which is not a useful behavior. It would be effectively redundant with the functionality provided by the Drupal "Require e-mail verification" account setting.
I am updating the patch to disallow the combination of settings.
Comment #6
AohRveTPV CreditAttribution: AohRveTPV commentedSorry for not getting back sooner on this. I want to get this feature in.
Wrote a new patch:
1. Change setting to "Force password change by e-mail" and do not log user out.
To me it seems the purpose of this feature is to force the user to reset their password via e-mail. Verifying ownership of the registered e-mail address is another way of authenticating the user when the password might be compromised.
Logging out the user is a way to accomplish this, but does not seem necessary. We can just force the user to be redirected to the "Request new password" page.
2. Patch in #3 looks to allow an access bypass. If a user is forced to change their password, and they log in directly from the password change page (e.g.,
user/2/edit
), they would not be logged out.3. Make this the default setting for new installations. Allowing a user whose password is expired, for instance, to change their password using only the expired password to authenticate, is insecure. Existing installations will have this setting off so the behavior does not change unexpectedly after update.
Please review. I would be especially interested to know what is thought about the change to not log the user out. Is there any problem doing it this way?
Comment #7
AohRveTPV CreditAttribution: AohRveTPV commentedMinor simplification versus #6.
Comment #10
AohRveTPV CreditAttribution: AohRveTPV commentedChanges versus #7:
- Fix syntax error.
- Add test.
- Change setting to default to off. (I am still thinking it should be the default, but it can be made the default later. Probably should allow for some post-release testing of the feature first.)
Comment #11
AohRveTPV CreditAttribution: AohRveTPV commentedVersus #10, tried to clarify the setting description.
Comment #12
AohRveTPV CreditAttribution: AohRveTPV commentedSetting needs to go under "Settings" tab, not "Force password change" tab. A user with the "Force password change" permission should be able to force password changes, but not change how forced password changes work.
Comment #13
AohRveTPV CreditAttribution: AohRveTPV commentedAdd "Force password change settings" fieldset on configuration page and put "Force password change by e-mail" setting there, per #12.
Comment #14
anemirovsky CreditAttribution: anemirovsky commentedThe code looks good. The only problem I see with not forcing the user to be logged out is that they then have to manually log themselves out in order to be able to reset their password via the link provided in the password reset email. So, it's nice that they are redirected to the reset password by email page, but after clicking "E-mail new password" they then have to follow the direction on that page that says "You must log out to use the password reset link in the e-mail."
My guess (based on answering a fair amount of support requests from clients surrounding resetting passwords) is that a lot of people are not going to read that and are not going to log out. Then, when they click the link in the password reset email, it's going to take them right back to the reset password by email page with a message like "You are logged in as . Change your password [which is a link to the user edit page]." If they click "Change your password", it just takes them right back to the reset password by email page. So, basically, they're in an endless loop until they manually log out. That's why I think it makes more sense to just log them out.
Comment #15
AohRveTPV CreditAttribution: AohRveTPV commentedAgreed. I see two possible solutions:
Solution 1:
- Add a submit handler for the button to log them out once they press the button.
- Change the text to remove the sentence about logging out.
Solution 2:
- Log out the user immediately if they are forced to change their password, and redirect them to the
user/password
page with a message explaining what to do.Solution 1 seems like it might be simpler for the user because they only have to enter their username once. Do you agree? Solution 2 may be preferable if it is simpler to implement.
Your patch in #3 implemented solution 2, but I did not see any message explaining to the user what to do when I tested. The user would just be logged out and redirected without any explanation. (I might have misapplied the patch though.)
Comment #16
anemirovsky CreditAttribution: anemirovsky commentedIt's been a while, but I believe it should have added a message like, 'Your password has expired. You have been logged out and must change your password to proceed on the site.'
I like option 1 better, too, so if that works, I think going that route is preferred.
Comment #17
AohRveTPV CreditAttribution: AohRveTPV commentedChanged to automatically log user out upon submission.
The default message seems to be removed by logging out so I duplicated it in
password_policy_user_pass_submit()
.Comment #18
AohRveTPV CreditAttribution: AohRveTPV commentedDiff between #13 and #17.
Comment #19
anemirovsky CreditAttribution: anemirovsky commentedI gave the latest patch a test and it looks good to me. Nice work!
Comment #20
AohRveTPV CreditAttribution: AohRveTPV commentedMinor formatting change per coding standards.
Comment #22
AohRveTPV CreditAttribution: AohRveTPV commentedThanks for reviewing/testing. Went ahead and committed so this can hopefully get some testing in use. I think the messages might need some improvement, but that can be done with further commits.
Comment #23
AohRveTPV CreditAttribution: AohRveTPV commentedThis feature in 7.x-1.x seems to have a problem: It will start prompting the user to change their password via e-mail during the warning period before expiration. I think it should only be asking the user to change their password via e-mail upon expiration. Will open a new issue for this.
Comment #24
AohRveTPV CreditAttribution: AohRveTPV commentedOpened issue per #23: #2543966: Password change should not be forced by e-mail during expiration warning period
This is only a problem if using the expiration constraint with the "Force password change by e-mail" setting enabled.
Comment #25
AohRveTPV CreditAttribution: AohRveTPV commentedPatch to revert this feature.
I would like to make a Password Policy release for some bug fixes, but this feature still has at least one serious bug per #23/#24. Planning to re-add feature after release.
Comment #27
AohRveTPV CreditAttribution: AohRveTPV commentedUndid reversion of a few lines that shouldn't have been reverted in last patch.
Comment #29
AohRveTPV CreditAttribution: AohRveTPV commentedComment #30
AohRveTPV CreditAttribution: AohRveTPV commentedFuture implementations of this feature should not force the user to change their password by e-mail during the expiration warning period. Password changes should only be forced by e-mail when (a) the password has expired, or (b) a password change has been forced for the user by an administrator.
See #2543966: Password change should not be forced by e-mail during expiration warning period for more details. (Note I am closing it because it is a bug report for a bug that no longer exists, since we reverted #21.)