In a hypothetical website, there are two types of users, admin users and normal users. Normal users can change their own password, and in keeping with best practices are required to provide their current password when doing so.

Admin users can change the password of any user. Should they be required to confirm their password when doing so?

  • 2
    Admin must be authenticated before doing administrative tasks, such as changing other user's password. Admins do not have to know the user's passwords (old and new) to do so. Admins can be asked to input some data that cannot be automated, such as typing their password, before performing sensitive administrative tasks to prevent XSS attacks.
    – A. Hersean
    Commented Oct 23, 2018 at 16:25
  • 1
    I would suggest that they have to confirm there password - what happens if they leave their desk unaccompanied. Anyone can change anyone else's password without confirmation.
    – KingJohnno
    Commented Oct 24, 2018 at 11:53

6 Answers 6


This is an anti-pattern of least privilege principle. In common case, a "reset password" button should be enough, which will lead a target user to password reset form.

But if you need exactly "set new password" button, then you shold consider two relevant attack vectors - CSRF and XSS. If you'll mitigate them well - that should be pretty enough without additional authentication.

  • 2
    Resetting a password is a different action than changing a password, and when changing a password it is a common use case (and a good call IMO) to ask the user to verify their password. This is intended to make sure that an attacker with temporary access to their account can't change the password, gaining permanent access and locking out the owner. Commented Oct 24, 2018 at 12:07
  • You're correct that if you mitigate XSS well then you don't have to worry, but saying that is not especially helpful without talking through what that actually means. In particular, the only way (I can think of) to stop an XSS from taking advantage of a "set password" page is by requiring the user to enter their password on that page. As a result, I think you've missed the crux of the question. Commented Oct 24, 2018 at 12:09

The decision is likely to come down to the admin user profile. For dedicated admin teams there may be other supplemental controls such as restrictions on the devices that can be used, device hardening and access controlled ops rooms to reduce the risk of attacks. These supplemental controls may remove the need to require re-authentication prior to allowing reset of someone else's password.

If admin responsibilities have been devolved partially or fully to trusted users amongst the user community, for example in a branch office, then there is the possibility of normal users or even members of the public having access to the same devices as the admin users.

To try and prevent misuse of privilege in this scenario it might be appropriate to require secondary authentication to ensure that it is still the same (authorised) person requesting the password reset (i.e. to make sure they have not walked away and left a machine logged in by mistake).

  • Great answer, although I would add one more thing. As always, it depends on the use case for the company in question. If the website in question doesn't store anything sensitive for end users and there is nothing of real value in their profiles, then it may not matter enough for the extra security step (especially if resetting user's passwords is something that happens a lot). That being said, I would err on the side of caution when it comes to resetting user's passwords, and I think an extra security step would be a good move by default. Commented Oct 24, 2018 at 12:17
  • @ConorMancone - Agreed, though I did not want to take the possibilities too far, for example if something is not sensitive enough to warrant any particularly robust protection I would anticipate self-service password reset being available and admin resets would be largely unnecessary. I'll give it some thought and see what I can add without going too crazy with 'what-ifs'!
    – R15
    Commented Oct 24, 2018 at 14:43
  • Yeah, more often then not I simple don't allow admin-driven password resets. IMO I think they are actually pretty dangerous themselves, and I usually prefer to leave users in charge of their own access as much as possible. Commented Oct 24, 2018 at 15:10
  • Pointing out that limiting by device is also a form of secondary authentication, so your point is kind of moot. Some form of secondary authentication is necessary, and depending on the field, tertiary authentication may also be advisable
    – Mars
    Commented Oct 9, 2020 at 3:17

Admin users can change the password of any user. Should they be required to confirm their password when doing so?

The website could prompt the admin user for his password on each setting change including password reset for normal user.
Regardless of this policy being good or bad, you want just confirm that the right user is performing admin tasks, this is different for normal user case where the purpose of requesting current password is to make sur the right user has access to right account.


Probably not beneficial to make them re-enter their password for an action like resetting a user password - you already made the admin user authenticate to your system. You could make every user enter their password for every possible action and it would be “more secure,” but not meaningfully so. Additionally, resetting a password is not an especially sensitive action for an admin user to take (not like deleting a resource, for example)

Assuming you are already properly authenticating the admin user in the first place, and that you are protecting from other cross site attacks, this would only really address two scenarios

  1. Your website doesn’t automatically log out users, and an admin user logged on the left their workstation available for another person to physically hijack - an extra password check would mitigate this (admittedly unlikely) vulnerability. You should be automatically logging users off at regular intervals of inactivity anyway, particularly privileged users.
  2. You want to make the admin consider carefully if they actually want to perform the reset - analogous to deleting a repository on GitHub it a virtual machine in Azure where you have to type the name of the resource you’re trying to delete. Resetting a password is typically not as big of a deal as deleting resources though, so this also seems not very beneficial compared to the hassle for the admin users.

Not much benefit in any case. You would be better served by making sure things like two-factor authentication work and protecting against cross site attacks.

  • "and that you are protecting from other cross site attacks" - Filtering cross-site attacks is never perfect, so it's reasonable to take extra steps for such a sensitive function. Requiring that the admin re-enter their own password will hard shut down CSRF, XSS, etc, and make clickjacking far more difficult.
    – ThrawnCA
    Commented Oct 24, 2018 at 0:54
  • I strongly disagree with this statement: "resetting a password is not an especially sensitive action for an admin". Imagine someone who takes over an admin account for an ecommerce system, resets passwords for individual users, and then logs in to those accounts to place orders for themselves using the user's stored credit cards. That's a bit of a contrived example, but there are plenty of use cases where an attacker with the ability to reset any arbitrary user's password might do extensive damage. Commented Oct 24, 2018 at 12:12
  • @ConorMancone which is why you log the action like every system that uses passwords and allows them to be reset, it is an inherently privileged action but so are literally all admin actions. A password reset isn’t significantly more sensitive than any other admin action, and again, you already made the admin user authenticate in this scenario.
    – John-M
    Commented Oct 24, 2018 at 12:26
  • @John-M I disagree. Yes, most admin actions are privileged actions, but some are still more dangerous than others. It obviously depends on your particular use case but in general I would say that an action that can give the admin direct access to other people's accounts is an especially dangerous action that deserves extra scrutiny. Personally I would just leave such an action out all together (and let the user's use a standard password reset), but if I put it in I would grant extra security to such an action. Commented Oct 24, 2018 at 13:16
  • @John-M Although to be fair "Admin" is really a very broad term. As a for instance, an admin in an ecommerce system may be responsible for processing orders or refunding payments. I wouldn't give those extra security. Sure, an attacker could take over an admin, place an order themselves, refund their payment, and then mark their order for regular processing, but separate parts of the business will likely catch this (aka accounting). The inconvenience of putting in your password everytime you process an order probably outweighs the actual risk. Commented Oct 24, 2018 at 13:19

Admin users can change the password of any user. Should they be required to confirm their password when doing so?

Not necessarily. Provided that the admin should NOT have the ability to select the user's password string. The admin could trigger a password reset action which would send an email to the user with a link to reset his/her password.

If above such system is not possible and admin needs to reset the password for users then asking admin's password for each password reset could be cumbersome, for example, if the admin needs to reset hundreds of passwords in a batch. This would not an efficient security measure and might lead to single point of failure.



Other answers somewhat touch on it, but they aren't quite clearly identifying what the real deciding factor is.

Where is the risk? What is at risk?

Where is the risk?

Assuming your API doesn't have a vulnerability, the real risk case is when an admin leaves their PC open while they grab coffee. Someone could make some changes and no one would know who did it. They will at least know WHAT was done, if it's logged properly.

What is at risk?

If the admin can set the user password, then you are risking that in the above attack, someone could gain access to someone else's account and impersonate them. The above attack leaves users open to identity theft, with whatever powers you grant users, plus whatever information you store for them.


Prompting for a password is an easy to implement fix to the where.
Given the simplicity, it's hard to think of any scenario where it isn't worth implementing.

But don't stop there. Evaluate your other risks--in the above attack, is there anything else that an attacker could change in order to gain something? If there is, a password should be required for any of those changes too.


  • Changes in permissions for users. Can an attacker give them self access to new data?
  • Changes in functions. Can an attacker break your site, especially in a way that might not be noticed easily? (Disable a particular web page, turn off a webhook, etc)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .