Make WordPress Core

Opened 13 years ago

Last modified 5 months ago

#20140 reopened feature request

Ask old password to change user password

Reported by: nprasath002's profile nprasath002 Owned by:
Milestone: Future Release Priority: normal
Severity: major Version:
Component: Security Keywords: has-patch 2nd-opinion
Focuses: ui, administration Cc:

Description

I have experienced this in various sites and i think
it adds extra security.
We must ask for the old password when the user tries to change the password

Attachments (3)

20140.diff (3.7 KB) - added by bootsz 12 years ago.
Adds "Current Password" field to the profile & user-edit pages.
20140.2.diff (3.0 KB) - added by iandunn 11 years ago.
20140.3.diff (3.1 KB) - added by nacin 11 years ago.

Download all attachments as: .zip

Change History (33)

#1 @tman4506
12 years ago

  • Owner set to tman4506
  • Status changed from new to reviewing

#2 @tman4506
12 years ago

  • Component changed from Administration to Security

#3 in reply to: ↑ description @tman4506
12 years ago

Replying to nprasath002:

I have experienced this in various sites and i think
it adds extra security.
We must ask for the old password when the user tries to change the

I I think it's a great idea. I'll work on it no guarantees though

#4 @tman4506
12 years ago

  • Status changed from reviewing to accepted

#6 @bootsz
12 years ago

  • Cc sbutze@… added
  • Keywords has-patch dev-feedback added

@bootsz
12 years ago

Adds "Current Password" field to the profile & user-edit pages.

#7 @iandunn
11 years ago

  • Cc ian.dunn@… added
  • Keywords needs-refresh added

+1

This was initially rejected in #4444, but I still think it's a good idea.

Most authentication systems employ this feature. Otherwise, an attacker could just walk up to a laptop while the owner isn't looking and change the password. It's easy to implement and doesn't place an unreasonable burden on the user.

One of of the reasons it was rejected was that "Someone with such access could install a backdoor, create a new user, or do any number of other things to engineer future access", but that assumes the current user is an Admin. They could be an Editor or other role.

Looks like the patch needs to be refreshed (and generated from / instead of /wp-admin).

#8 @azaozz
11 years ago

Thinking more about this: when users change their own passwords typing the old password is more or less expected and adds some security.

That's not the case when an admin is changing another user's password. The current patch also requires the admin to know the user's current password to be able to change it. That's not acceptable.

#9 @iandunn
11 years ago

Yup, I just noticed that too. I'm working on a refresh that allows admins to change it without knowing the current one.

Last edited 11 years ago by iandunn (previous) (diff)

@iandunn
11 years ago

#10 follow-up: @iandunn
11 years ago

  • Keywords needs-refresh removed

20140.2.diff refreshes the original patch, and allows admins to change other users' passwords without having to know what the current one is.

#11 @SergeyBiryukov
11 years ago

  • Milestone changed from Awaiting Review to 3.7
  • Owner tman4506 deleted
  • Status changed from accepted to assigned

#12 in reply to: ↑ 10 @DrewAPicture
11 years ago

Replying to iandunn:

20140.2.diff refreshes the original patch, and allows admins to change other users' passwords without having to know what the current one is.

Shouldn't we check whether that user can be edited by the current user rather than saying only administrators can change a user's password?

Last edited 11 years ago by DrewAPicture (previous) (diff)

#13 @iandunn
11 years ago

Shouldn't we check whether that user can be edited by the current user rather than saying only administrators can change a user's password?

The patch doesn't actually change any of the behavior related to capabilities; I just wasn't being precise when I said "administrators". The patch uses IS_PROFILE_PAGE to determine whether or not the extra field should be generated and validated, so if there's a custom role that can edit users then it shouldn't be affected at all.

@nacin
11 years ago

#14 @nacin
11 years ago

  • Keywords commit 2nd-opinion added; dev-feedback removed

I could go for this. 20140.3.diff is a clean-up.

I guarantee it'll take only a few days for us to receive a security report that states an administrator can simply create a new user, then log in as that user to change the first administrator's password. At the same time, though, that obviously could already happen.

This is designed for better user security for sub-administrator roles. Which is good, because they're commonly being used in attacks.

I'm going to put this on the agenda for Wednesday's meeting. Marking for commit (dev-wise) pending feedback as to whether we want this.

#16 @iandunn
11 years ago

xref: http://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2013-09-25&sort=asc#m696129

TL;DR: Instead of putting it in 3.7 as-in, we should look at expanding the scope and adding some extra protections for 3.8.

#17 @nacin
11 years ago

  • Milestone changed from 3.7 to Future Release

#18 in reply to: ↑ description @bundleplan
10 years ago

Thanks for this ticket! Is there any way to make this work for a frontend page? I currently have a theme that allows users to change password by a user profile in the front end but after a few days of trying, I can't get it to work (I don't know much code).

I can add the form for current pass no problem, but I just don't know how to modify both codes together, the closest I got was I changed the password, but not to anything I had put in the blanks.
Any tutorials on this?

Also another thing, can you make it so users cannot change other details, such as email address, without entering current password? I think it just adds more security is all, thanks again!

#19 @miss_jwo
10 years ago

Hi,

Is there any movement on this ticket?

This is coming up in ethical hacking reports as one of the ways to harden WordPress & therefore would be great if it was in core so that it is no longer an issue with ethical hacking reports.

#20 @stephenharris
10 years ago

As already mentioned that there are some difficulties in implementing this in a meaningful way. An attacker who gains access to an admin account could do any of the following (even if this ticket is resolved):

  1. Create a new user with admin capabilities
  2. Change the e-mail address and use WordPress' 'forgot password?' feature
  3. Access the plug-in /theme editor and do all sort of nefarious things.

(3) is a special case in my opinion. There seems to be little appetite to remove it from core, so if a site admin decides not to disable it, then they are accepting the security risk it entails. The only solution would be to password protect those pages also which would be awkward to implement.

Leaving (3) aside, I think if this ticket were to be resolved (and I hope it would be), then we need to either password-protect the change of e-mail address or send a confirmation e-mail to the current e-mail address. Preferably giving the user a choice.

Additionally a password should be required when creating a user / changing a user's role / changing a user's password (that is the password of the user making the changes, not the user affected by the changes).

This may seem like a bit of a feature creep - but if this is to be implemented at all, we'd need to cover all bases. (Some interesting thoughts by Eric Mann related to this ticket .here: http://ttmm.io/tech/sudo-in-wordpress/).

I'd love to hear back from someone on the core team as to what the opinion on this ticket is. Is it a definite no-go? If not, would it be reasonabily considered if it were developed as a 'feature plug-in'? Are there any immediate blockers a developer of said plug-in should be aware of? ;)

#21 @johnbillion
10 years ago

A feature plugin would be an excellent way of beginning to address this.

#22 @miss_jwo
10 years ago

https://github.com/humanmade/hm-require-password something I had to build for a client.

If anyone wants to use it, feel free.

This ticket was mentioned in Slack in #core-passwords by stephenharris. View the logs.


10 years ago

#24 @stephenharris
10 years ago

Thanks Jenny, your plug-in served as an inspiration for this: https://github.com/stephenharris/password-confirm-action

The above password protects creating a new user, or editing the role/e-mail/password of a user. It uses a modal which appears after submitting the form provided it needs password confirmation (There's a non-js fallback).

Any help with this (even if its just using it & reporting problems) would be very much welcome. I'm hoping to put this forward as 'feature as plug-in' in the next release cycle. For those wishing to contribute code, unassigned issues are up for grabs ;)

#25 @wonderboymusic
9 years ago

  • Keywords commit removed

This ticket was mentioned in Slack in #core-passwords by juliobox. View the logs.


9 years ago

#28 @iandunn
6 years ago

  • Status changed from assigned to reopened

Reopening because I think this is still a useful enhancement.

#29 @SergeyBiryukov
6 years ago

  • Milestone set to Future Release

#30 @swissspidy
9 months ago

#60702 was marked as a duplicate.

#31 @dpknauss
5 months ago

  • Focuses ui administration added
  • Severity changed from normal to major

This is still a useful enhancement to limit the potential harm of a hijacked user session, but to fully eliminate that type of threat it would need to be applied to both user password and email address changes, as well as any new user account creation, like @stephenharris's plugin: https://wordpress.org/plugins/password-confirm-action/

Ideally, the privileged actions that trigger the challenge should terminate the current user session and require reauthentication to complete.

As Stephen's plugin notes, an Administrator with arbitrary upload/install/activate/deactivate privileges can bypass all of these (and any) defenses. Requiring reauthentication to perform upload/install/activate/deactivate/delete actions would adequately defend against hijacked Administrator sessions.

Since 2021, stolen session cookies from compromised user devices have become the most common effective attack (exceeding plugin vulnerabilities) on WordPress sites, so this old feature request has become even more relevant as a way to limit the potential damage.

Note: See TracTickets for help on using tickets.