Is it bad security practice to have a password that will allow you to access any user account on a website for support purposes? The password would be stored in a secure manner and would be super complex. Huge mistake?

  • 34
    Why not just have an administrator account that has privileges to modify other users' data?
    – Polynomial
    Feb 7, 2014 at 17:24
  • 1
    It seems like doing that would put another layer between the support staff and the problem account without providing much more security. Why do you think this would be more secure? Feb 7, 2014 at 17:35
  • 8
    @Polynomnial Usually an administrator 'sees' a different screen than a user, sometimes it would be helpful for support to see the exact screen a user sees when they are having trouble. (Not saying 'god' pw is good idea, but Admin account does not solve this specific issue - unless Admin has some ability to impersonate accounts.) Feb 7, 2014 at 22:09
  • 4
    There is already a way to do that. It's called sudo on any decent multi-user operating system. Feb 7, 2014 at 22:29
  • 17
    When asking questions of this sort, it's sometimes helpful to imagine that you're talking to an internal auditor and trying to explain why you put this feature in. You:"So, we've got this 'god' password". Internal Auditor:"'God' password - kind of like a back door, right?" You:"Um, well, sort of, but..." Auditor:"GUARDS! OFF WITH 'IS 'EAD!!!!!" Puts it all in perspective, doesn't it? Feb 9, 2014 at 3:41

10 Answers 10


This sounds very much like an "Administrator" account, which typically otherwise has unlimited access to the things that it's the administrator of.

The security implications of an admin account are pretty well-understood, as are the best practices. I won't go in to all the details, but your implementation breaks with best-practice on one key feature: traceablity.

You want to be able to tell who did what, especially when it comes to administrators. If an admin can log in to my account using his password, then there's no way for an auditor after-the-fact to determine what was done by me versus what was done by the admin.

But if instead the admin logs in to his OWN account with his super-secure password, then through the access he has through his own account performs some action I could have done as well -- well then now we can have a log telling who did what. This is pretty key when the manure hits the fan. And even more so when one of the admin accounts get compromised (which it will, despite your best efforts).

Also, say the business grows and you need 2 admins. Do they share the superawesome password? NO NO NO. They both get their own admin accounts, with separate tracing and logging and all that. Now you can tell WHICH admin did what. And, most importantly, you can close one of the accounts when you fire one of the admins for stealing the donuts.

  • 3
    On a related note, while it's often necessary to have a means for administrators to change account passwords, one should as a matter of policy not have the administrators set accounts to directly-usable passwords, but instead set them so that a user must set his own password before using the account. In that way, anything done with an account may be attributed to the most recent person who set the account's password. If Bob is unwilling to log in with any password not set by himself, his password is changed on Monday, and on Thursday he is known to log in, those facts together would imply...
    – supercat
    Feb 7, 2014 at 20:23
  • 3
    @joshuahedlund That is what screen-sharing tools like VNC, TeamViewer, Remote Assistance, WEbEx, etc... are for. You never impersonate the user. You view a copy of his/her screen as if you are standing behind them looking over their shoulder.
    – Tonny
    Feb 7, 2014 at 23:15
  • 13
    @joshuahedlund A backend system I recently wrote has a feature like this. An admin clicks a "log on as this user" button, and it the system behaves exactly as though the admin WAS that user. Everything is kept straight in the logs, though.
    – tylerl
    Feb 7, 2014 at 23:58
  • 7
    This account has been terminated for the following reason: unauthorized access to donuts.
    – Thomas
    Feb 8, 2014 at 9:08
  • 3
    @Thomas: No, no. It's not the access that is unauthorized, it's the denial of donut service to other users that got him canned.
    – Ben Voigt
    Feb 8, 2014 at 16:30

There is a lot of great information in the answers given so far that the original poster should read and take to heart. However, I think most of the answers do not capture the spirit of the question as it relates to traversing their company's website "as if they are the user" for support purposes. The heart of the question appears to be that this activity occurs on the front-end of a website rather than the console of a server.

I know of a company that has this same need in it's web application and has already solved it in a way that I believe is the kind of solution the original poster was looking for.

They created a "masquerade" system in their webapp that allows an employee in a special group to enter a set of pages that can look up any user in the system and select that user as the credentials to browse the system with. It tracks the user selected to masquerade as and the actual employee user as two separate and simultaneous entities that are both recorded at all times, and for every action.

From the application's perspective it is a "treat me as this user, but remember that I'm actually this other user." Sort of a webapp version of sudo, but built into the front-end.

This method:

  1. Eliminates the audit trail nightmare, because both user accounts are always tracked.
  2. Provides employees an exact "user view" of pages.
  3. Maintains individual credentials for the employees so that there is no shared or "master" password.
  4. Maintains security for users, whose passwords are never available to employees.
  5. Keeps the solution at the application layer, on the website, so that anyone can do it without systems level access or knowledge.
  6. The employee can also "unmasquerade" at any time and check page content against their own account or other user accounts, which is very helpful in determining whether bugs are global or user-specific.
  • 3
    Looks to me that this answer is the closest one to OP problem. An administrative account is not the solution as it has a different visibility/behaviour than the one of the user being troubleshooted.
    – WoJ
    Feb 8, 2014 at 16:54
  • I agree with this answer. At my work we have a similar functionality built into our sites that allows an Administrator to "Impersonate" any other user. It allows the Administrator to see and use the site exactly as the impersonated user while still allowing for appropriate security and logging.
    – mezoid
    Feb 10, 2014 at 0:16
  • The phpBB forum software has this functionality built in, for a good example.
    – KRyan
    Feb 11, 2014 at 4:27

Yes, it is a mistake. What happens if attacker manages to get a hold of this password, no matter how secure you think it is? He will be able to tamper with user account information in a way that is most likely difficult to differentiate from normal activity.

If you control the website, you already have many different methods available to you for support option. Proper administrative tools can be written to read and modify the necessary information. There is not much point in have a "master" password.

  • Wouldn't proper administrative tools pose the same (or at least a very similar) threat? Feb 7, 2014 at 17:28
  • 4
    @AbeMiessler No... Because if you're using individual admin accounts, logging shows what happened and who to fire for putting their password on a post-it.
    – Basic
    Feb 8, 2014 at 1:29

This "god" password is the equivalent of root / Administrator access: can do everything. The question is twofold:

  1. Is is a good idea to have some sort of access of the "can do everything" kind ? In practice, it is more "unavoidable" than "good", but yes, it is a normal thing. Be sure, though, to have appropriate usage procedures: you don't want administrators to do administration from a shared machine in a coffee shop; and you want to know "who dunn'it". In that sense, when there are two or more individual empowered with administrator privileges, it is best if they act "as themselves" as members of an administrator group (in the Unix world, use sudo so that commands are logged).

  2. Is it a good idea to make administrators exert their privileges through the normal user API ? This one is debatable. Allowing a "god password" means installing the "god exception" throughout your application, which runs the risk of it being abused. It increases the complexity of the authentication+authorisation system in your site, and complexity is the one thing you want to avoid in security. Bugs thrive in complexity. A "god password" can be convenient during development, but, generally speaking, it tends to increase the likelihood of a devastating security hole, so use with extreme caution.

Of course the context is everything, and the answers above merely usually apply. Still, be wary of administrative backdoors, in particular backdoors which do not keep a good track record of the origin of administrative requests.

  • Your comment about "unavoidable" versus "good" brings up an interesting point. If the design of a system is such that someone with physical access would be capable of doing anything and everything, including undetectably modifying the audit trail, then it may be reasonable to allow those with physical access to do such things conveniently. Having such things be inconvenient but not impossible would introduce inconvenience but not get the traceability advantages that would arise from them being impossible. One thing I've sometimes thought would be a useful product for someone...
    – supercat
    Feb 9, 2014 at 17:00
  • ...to sell would be a "logging box" which was designed so that any log records which were committed could not be removed within a certain period of time without physically breaking into it. If the device was limited to accepting data at a rate of 30MB/minute, for example, a device with 64GB of flash could guarantee that it would take over a day of constant maximum-data-rate flooding for someone to overwrite a log entry. If the box included public-key crypto on its readout/status functions, someone could have totally unlimited access to a machine with such a box...
    – supercat
    Feb 9, 2014 at 17:07
  • ...but if the log-box recorded who acquired such access, that record would be almost indelible (if some other machine periodically polled log-box, and would squawk if it couldn't access it for a few hours, that could notify security personnel that something was amiss, and that they had a certain amount of time to step in before audit information might get destroyed).
    – supercat
    Feb 9, 2014 at 17:10

An Administrator can still only act as himself: someone with a god password can impersonate anyone on the system. One could argue that if the Administrator has enough power, this doesn't do much to limit the actual damage an attacker with that account could do. But an attacker with the god password would have a much easier time of covering his tracks.


Having a "god" password is a simple solution, but it is merely an "authorization" by way of knowing the master password, and does not lend itself to good access management (i.e. controlling who can do it), nor accountability (who really did what).

Instead, change your credentials data structure to have an effective-user field:

  user: alice,
  effective_user: bob,

The content of your webpages should be rendered for the effective_user, unless it is an internal administrative page that needs to know who is really browsing. Note that most external people browsing your site will always have the same id for both fields:

  user: alice,
  effective_user: alice,

This arrangement permits you to better control who is allowed to become another user, and it also permits you to record/audit who did what on who's behalf. (You can simply log both the user and effective_user on things you care to watch.) Unix does this effective user (and group) sort of thing internally if you look at the sources for what defines a process. Mimicking this on the web is leveraging a known, successful paradigm.

This solution also allows you to choose which pages your staff can "look over the shoulder" of another user. You can choose to write a page that does not render based on the effective_user, then none of that page can be seen by your staff even if they have the privilege to change their effective user id.

BTW, I have implemented the effective user concept on the web, and I have also implemented the god-password. The latter is easy to drop-in when all the infrastructure is already in place. But it really is not the best solution in terms of knowing who did what, and managing access. Take a close look at how much refactoring is really involved to add the effective user field -- it may be less than you think.


You never impersonate the user. (For various reasons of trace-ability/accountability as others already mentioned.)
In stead you view a copy of the users screen screen as if you are standing behind them looking over their shoulder.
That is what screen/desktop-sharing tools like VNC, TeamViewer, Remote Assistance, etc... are for.

  • 1
    I don't think you have thought through the practicalities of that statement. For example when I am on Facebook and I want to see the result of my permissions instead of using 'view as ...' I should go ask one of my friends to install vnc and visit my page? While a screenshare may be appropriate in troubleshooting there are many cases where seeing behavior of the website as a given user should never involve the user themselves eg. testing/validation of settings or a bugfix.
    – JamesRyan
    Feb 11, 2014 at 12:13

If only one person has access, then it isn't necessarily a problem, however it can just as easily be done through having a setting for a user account that allows this access.

With any root/superuser/admin kind of functionality, logging and auditing of behavior is critical, and that means you need to know who was doing what. If multiple users need to be able to make changes like this, then it should be a flag on their account to allow for it.

You may still want to have an additional, more complicated password that has to be entered even when they have access, but you should require secure authentication of an individual who is making changes before doing anything of this nature.


You may not have a choice but to have a 'god' password. Regardless of what tylerl said about having two different administrator passwords, how would it even be possible to have a log and tracing unless someone was in charge of that, too? You would literally have to encrypt the log and everything against yourself in such a way that it is read only to the outside world but can still write for itself. How does it determine whether the information it is receiving is legitimate or not then? Obviously if you don't have access, then no one does so that wouldn't work either.


I think you need to have role based security rather than one account with "god" mode abilities. This way you can have multiple people who have the same roles with similar capabilities so that if your god/admin is not available, someone else can go in an make the fix.

I know that this is preferred specially if you are going to be audited.

You must log in to answer this question.

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