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).

  • 2
    Are you are really asking if admin's should be able to reset (rather than edit) passwords? – JonnyBoats Mar 1 '12 at 23:16
  • I can't think of any applications where this isn't the case. – tylerl Mar 1 '12 at 23:37
  • @JonnyBoats - Yes, I guess manual reset would be a better way to describe it. They would basically see empty password fields and be able to fill them in. – VirtuosiMedia Mar 2 '12 at 7:35
  • 1
    As your question is currently ask, this would mean the password was stored in plain text, which clearly should not be done. Being able to reset the password, and generate a new random password, and send it to the user is fine provided it can only be used once. A password SHOULD NEVER be sent in plain text if it can be used more then once. – Ramhound Mar 2 '12 at 17:27
  • Yes I think an admin should be able to do that. If not, it would harm his ability to do his job. It's like taking the building keys away from the janitor, and asking him to administrate things. An admin should only be able to reset the password, but not view it because it's supposed to be a secret. – Wadih M. Mar 10 '12 at 2:29

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.

  • 12
    Setting a user's password to an admin chosen value, should also set a flag that forces the user to change the password on the next login. – CodesInChaos Mar 2 '12 at 14:42

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.

  • Administrators not only have access to modify user account passwords, but also generally the ability to modify or clear audit logs. With this, a malicious Administrator could effectively impersonate a chosen user to do whatever activities they might not want associated with their own account. Whether the user account grants the Administrator any access they would not have under their own account is not the issue at this point - the problem is that the malicious activity may no longer be traceable back to its actual originator and, therefore, you also could lose non-repudiation. – Iszi Mar 2 '12 at 1:22
  • "Who Watches the Watchers" ? – woliveirajr Mar 2 '12 at 12:30

Necromancing here.
The very fact that you ask this question tells me that your method of storing passwords is horribly WRONG.

This question shouldn't even exist, because if you stored passwords securely (via cryptographic-strength hash, with salt), you technically couldn't uncover any password, not even with rainbow-tables.
All you can do is reset the password, and that's certainly not the admin's job.

If you store passwords in plain text or encrypted, this is wrong. An attacker (might be just a kid, but could also be organized crime an intelligence agency, possibly of a not-so-nice state) that gains access to your database (and code) can get the (most likely symmetric) key, and uncover all passwords of all users.

Users have a tendency to enter the same username + password everywhere, so by compromising your website, an attacker might gain access to many user's account, e.g. Amazon, FB, E-Mail, Microsoft, Google Docs, etc. ...

Storing passwords plain-text and encrypted is therefore a very bad idea
It is conceivable that in certain jurisdiction, you (or your company) might be liable for the damages as well.

You should always store passwords with a slow cryptographically secure hashing algorithm that is properly salted, in which case it's (hopefully) technically impossible to uncover a password.

  • 2
    The question says "Even with edit ability, the admin would never see the current password." A better phrasing is "should the admin be able to reset the password." – cpast Jan 14 '15 at 9:01
  • 1
    This answer is true, but irrelevant, for the reason cpast mentioned. The question does not assume that the admin would be able to read an existing password. – Gilles Jan 14 '15 at 14:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.