Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

This question already has an answer here:

We're a website developer agency, and most of our websites are made using in Wordpress, Joomla or Drupal as a CMS.

I'm having trouble to decide how we should manage our passwords, and I'm open for suggestions.

We could:

  • Use a default password for every website (big no)
  • Generate an unique password for every website and keep it in a database (make the database accessible from only our office's IP would be a big plus, but then in case of an emergency, it could make things worse if nobody is in the office.)

My main concern is not only keeping de passwords safe among the employees, but most importantly is keeping the passwords safe against the ex-employees.

I've had a case where an employee quit, and the next day he entered one of our websites and defaced the whole website.

Unlike servers, I can't use private-keys in this case, as we do to access our servers.

Any suggestions?

share|improve this question

marked as duplicate by Xander, Adnan, TildalWave, NULLZ, Terry Chia Aug 28 '13 at 1:22

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

add comment

6 Answers 6

You cannot enforce forgetfulness; if an employee could, at some point, learn a password, and indeed typed it in the course of his job, then he may still remember it even when no longer an employee, and you cannot force him to "forget".

Therefore, the only way to "destroy" a password access is to invalidate that specific password. The "good" way is to make it so that each employee has his own administrative password. On the day the employee leaves, invalidate this password on all sites where it is active. If the employee leaves under some distrustful conditions, invalidate his password five minutes before you tell him that he is fired.

If you must share passwords because of some technical limitation (e.g. some site software which recognizes only a single "admin password"), then the only way to invalidate the password is to change it, and give the new password to all remaining employees.

Since each employee may end up with a lot of passwords to remember, they will need some kind of storage system. I have seen people use this product and be happy with it, but I don't believe this is the only one of its kind.

share|improve this answer
add comment

The go-to answer would be to use the features of the CMS you are developing within for that particular website, and create an account, with unique password, for each person who is authorized to be inside that website as a developer. Users could then put these passwords into a centralized system like DICEware or KeePass, and go anywhere they need to with one master password. The advantage is that you use what you're given. The downside would be having to navigate several CMSes separately for even basic user administration, as well as having to put up with the varying levels of functionality each CMS provides in terms of auditing and content protection. There may also be increased subscriber costs involved in having that many users, both on your side and the clients'.

The second answer would be to develop a centralized system to control access to each of your CMSes; users would log in to this system, which would then act as a pass-through proxy for the editing capabilities of all the websites your teams control by using a single account for each CMS. The upside is one gateway and thus one gatekeeper, and theoretically this system can allow, restrict and log whatever you like regarding user actions. The downside is increased complexity, and the requirement that all portals have the ability to authenticate users in such a way that even the actor using the system can't learn the credentials.

A hybrid approach is authentication using a OpenID provider. Require all users to create a GMail account or similar Google ID for the job, which they'll use to log in to a session. Your websites can then be logged into using Google, identifying the CMS user as the Google user. The upside is one login, one time. The downside is that you still have to go into each CMS and enable or disable accounts, because you don't control access to the Google ID created by the user. You can mitigate this by implementing your own OpenID provider that the websites will look to, based on the user's Active Directory login or some other centralized authentication system.

share|improve this answer
add comment

I'm assuming you are using the same username and password for all employees that need to access the admin? If this is the case then I would recommend creating and admin account for each employee that needs access. So say you manage mysite.com, create the following admin accounts:

Abe
Chuck
Employee to be terminated

Instead of just having a single "admin" account.

Then when an employee is terminated, you would need to go to every site they have access to and delete the account.

Otherwise whenever an employee is terminated you will need to change all passwords for the websites you manage.

share|improve this answer
add comment

You really want to have the various sites all trust your authentication server and have each developer use their own credentials. The easiest way might be to use OAuth. This way, each developer's account on multiple sites will be controlled from a single shutoff point. They can use their own credentials to log in to whatever sites they need but then shutting them out is just a matter of deactivating their OAuth account.

share|improve this answer
add comment

Give each developer their own admin account on each server and revoke as needed.

share|improve this answer
add comment

You could consider a commercial tool like Random Password Manager from Liebsoft, or PasswordVault from Cyber-Ark. They provide an auditable list of who has accessed the passwords, and they change the passwords on an as-used basis. You control access to the vault with your existing security system like Active Directory.

share|improve this answer
add comment

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