Suppose you have a user account management subsystem with a web UI. You can change user account passwords in regular masked input password fields in HTML POST forms. I'm wondering, is it fine if such forms have password confirmation text fields for user accounts you manage? In my opinion, password confirmation input fields are unnecessary, especially when there is multiple accounts processing by hand:

  • An admin can easily change the managed account password if something is not properly configured without any extra efforts (i.e., sending password reset emails, etc).
  • Sometimes it makes the admin to use clipboard to copy/paste passwords for managed users (having any sensitive data in clipboard is definitely a bad idea).

However, I think that password confirmation input fields are totally fine when changing own password, not someone else's one.

So, the question is: how fine is having password and password confirmation input fields for managing others user accounts? Is that idea good or bad?

(I'm working on a legacy project and making any changes to the project may not be trivial, but I'm still curious about that.)

2 Answers 2


Frame challenge

I would like to start with a frame challenge, as this is how I design my systems: an administrator should not be able to change other user's passwords. Of course the standard caveat applies: we all have different needs, and depending on what your system is storing, convenience may trump security and letting an admin change user's passwords might be the best choice for your business. However, I would say that if there is anything of value in the system then an administrator should not be able to change a user's password.

Instead, your system should have simple self-service password reset capabilities using modern best practices. In the event that someone is completely locked out of an account you can always create a separate "Account recovery" process that requires separate verification of identity and takes at least a few business days to get through (a slow account recovery gives the actual account owner time to respond if the attempted account recovery is not actually legitimate). Again, YMMV, and the techniques you employ will obviously depend upon the value of what your system is protecting.

The main reason for this is because allowing admins to change passwords can effectively destroy audit trails. "Administrator" doesn't (and shouldn't) mean "Has full access to absolutely everything", and allowing them to change a user's password potentially gives them the ability to evade any built-in auditing you have by taking over another user's account directly.

Finally, giving an admin the ability to change user passwords makes them a target for social engineering attacks if an attacker wants to gain access to someone else's account. Allowing admins to make changes to accounts is basically what landed AT&T in a $240 million lawsuit over crypto currency theft: https://www.theregister.co.uk/2018/08/15/att_sued_cryptocurrency/

Answering your question

Still, the best answer is not the only answer, so I wanted to answer your actual question. If you are going to give admin's the ability to change a user's password, whether or not you also ask them to provide their password to change the user's password depends on what you are trying to protect against.

The whole point of asking for a user's password when they change passwords is to protect against further privilege escalation if someone gets access to the user's session. Whether it is by stolen cookies or simply waiting until someone walks away from their computer with it unlocked, an attacker who gains authenticated access to someone's account could go and change their password to make their access permanent. Asking for the user's password before allowing a password change makes that much harder. The attacker is still in the system, but they can't lock out the original user and can't make their access permanent.

The same rule applies here, and therefore your choice depends on how secure you want this to be. If your admin works in the office, gets up for lunch, and leaves his computer unlocked and still logged in, then anyone could sit down and start changing user passwords. It's even better if they can go change another admin's password - then they have permanent admin access. Of course they could also just create another account and make themselves admin, giving themselves permanent access.

One way to prevent those kinds of attacks would be by asking the admin for their password before allowing sensitive changes (changing their password, changing another user's password, creating more admins, etc...). Ultimately though it is up to you to decide how to balance convenience vs security for your organization.


From my point of view the password confirmation field does not add security.


  • The admin must use a masked password input field to prevent password leakage by shoulder surfing.
  • The password confirmation field helps the admin to detect own typos done in the masked input by manually typing the password a 2nd time.

I agree with the other poster that you should avoid that admins directly set the user's password. Unfortunately that requires some out-of-band trust.

For Æ-DIR user accounts separate from normal e-mail accounts I'm using a two-step password reset procedure. But this requires that 1. the user still has access to the mailbox and 2. a zone admin is available to help within minutes.

You must log in to answer this question.

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