Should an admin user be able to edit passwords?

Question

For your typical web app, should an admin superuser have the right to edit a user's password, or should only that user have the right? (Even with edit ability, the admin would never see the current password).

Answer 1

I see three related questions:

Should an admin user be able to view a user's password? No. This is a bad idea. You should not expose (through the admin interface) a way for admin users to view other users' passwords. Some users may re-use passwords on multiple sites. Therefore, users should never be allowed to see the user's password.

Also, the only way to allow an admin user to view other users' passwords is to store those passwords in the clear (or, if any transformation is applied, it has to be reversible, in which case the passwords might as well be stored in the clear). This is bad security practice. Stored passwords should always be hashed, so that a breach of your database does not trivially reveal everyone's passwords -- and that means admin users won't be able to view other users' passwords.

Should an admin user be able to reset a user's password? Sure. That's useful. For instance, it is reasonable to give the admin user a way to reset the user's password, e.g., triggering an email to the user to allow them to log on and enter a new password, or generating a new password for the user and emailing it to the user. However, the system should not display the new password to the admin user. Also, in this case the user should get some notification that the admin reset their password (e.g., as part of the email that is sent to them), and preferably the action should be logged along with the identity of the admin user.

Should an admin user be able to set a user's password? This is useful and reasonable functionality to provide to an admin user. For instance, when creating new users, it is sometimes useful for an admin user to be able to generate a password for the user, enter it into the system, and communicate the password to the user over an out-of-band channel (e.g., over the phone). Similarly, it can also sometimes be useful if there's a way for the admin user to go to the screen to set a new password for the user, give the user the keyboard long enough to type in their preferred new password, and then click "ok" and set the user's password. These are reasonable use cases which you could reasonably support, without incurring significant security risks. In this case, the user should receive some notification that the admin reset their password (e.g., an email that is sent to them), and preferably the action should be logged along with the identity of the admin user.

Answer 2

You need to look at the overall security posture of the web application before you can say "yes" or "no".

The implicit question here is whether allowing the admin user the right to edit any user's password a breach of security. If someone were to abuse the admin superuser account (either a legitimate admin or a malicious attacker), what other things could they perform which are as bad or worse than being able to change a random user's password? For example, can they reset the user's email address where password reset emails are sent? Can they access the sensitive user info? If so, then altering passwords is not going to do any more harm and the attack vector is just as easy. (In fact, unless there is user data which is not available to even the super-user, malicious attacker access to the super-user account is the end-game.)

In addition, side-effects need to be taken into account. In Windows, if the Administrator changes a user's password, it can prevent access to previously encrypted data. The reason is because the user's password is used to derive the encryption key.

If you were to prevent the super-user account from being able to change passwords, then I believe -- from a system administration (and, yes, good customer service) perspective -- you still want to be able to allow a legitimate user to regain access to a locked or lost account. Whether this is by changing the password or some other method (one-time token) is entirely dependent on the situation.

If the situation is that you want to be able to prevent (accidental) misuse of the function by otherwise competent and non-hostile administrators, then protect sensitive functionality by requiring (further) elevation, prompts, copious audit controls, etc.