Bad practice to have a "god" password?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.