Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
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?
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.
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).
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
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.
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.
TL;DR: JUST DO IT.
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?
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.
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.
Examples:
