Best practices for storing production passwords for small groups

Question

This is not a technical question. How do small organizations keep sensitive information that must be shared among several individuals safe, such as root passwords to production servers? Not all people that need to have access work in the same location.. new passwords can be distributed by phone, but what rules should be enforced for team members in the storing of the passwords?

UPDATE: this question is not about the proper usage of root passwords -- that was just meant as an example. Maybe a better example would be the SSL passphrase or any other password that must be shared among people performing administrative tasks. The fact is, root passwords and the like need to be generated and stored and usually more than one person needs to have access, sometimes those people work in different locations. The question is about storage protocols. Thanks.

Answer 1

I personally recommend to people facing similar problems to use something like keepass or roboform to store passwords. These programs encrypt your passwords on a thumbdrive using a master password that the individual remembers, so that they need only remember the master password. In the event that someone looses their thumbdrive, they will have a window of time in which they can report the compromised thumbdrive, and allow you to change passwords. It will take a little bit of time, depending on the master password's strength, before the person who stole the thumb drive would be able to brute force the master password to get at all the other stored passwords.

Additionally, avoid having any account shared by more than 3 people, if at all! Instead, consider creating each individual an account with equivalent access. If a malicious employee has access to an account which they know is shared, it might be more tempting for them to do malicious things since they know you could not hold them accountable, since it could have been any of several people sharing the account.

This also means you don't have to change the password every time someone quits. Instead, you just disable/delete their account. So although you have more accounts to manage, you have less overhead when someone leaves since you don't have to notify everyone of a changed password.

Edit: Oh Roboform also has a online password sync service over SSL. So you could just have people retrieve passwords via syncing. It's kinda cool once you get used to it.

Answer 2

You shouldn't be handing out (or using) root passwords to any servers, production or otherwise. You shouldn't be sharing passwords.

People should log in as themselves (authentication) with their own user ids passwords; that's one half of the picture.

When properly logged in they should be given rights (the authorization side of the picture) as appropriate. You can use things like sudo for general OS purposes, and the rights mechanisms inside databases, etc.

These are two separate issues. Don't cross the streams!

Answer 3

With the advent of sudo we seldom need to use a root password any more. In my old shop, the root password was written on a card, sealed in an envelope, and locked in a drawer in the sysadmins' area. Those who needed to know had keys to the drawer.

Anybody opening the envelope was required to change the password and put the new password in a new sealed envelope. The envelope was not opened often.

This system is probably really bad professional practice, but in a small shop where everybody knew everybody, it worked well.

Answer 4

you can use a program like anypasswordpro to share passwords. It is encrypted and has levels of access :)

Answer 5

Be realistic. Whether you like it or not, people in small teams are going to write passwords on sticky notes, IM them, or be tempted to email them, especially when they perceive no threat.

One measure I've found useful with small groups is to establish an obfuscation protocol.

For example, all passwords communicated or stored via voicemail, email, IM, or paper will have 1) the order of their characters reversed 2) a random character or word placed in between each password character 3) phonetically pronounced password characters.

For example:

Password: VMaccp@ss1

Obfuscated: one 2 es df es 23 at sd pee fd see dfs see fxz ay df EM sd VEE

The key is to establish some kind of encoding that is virtually impossible for someone to figure out without knowing the protocol, which is easy to remember.

Keep in mind this is for small groups without life-or-death security. Obviously for larger groups or those protecting extremely sensitive financial data stronger more cumbersome measures are appropriate.

Answer 6

In a prototype & R&D lab where I formerly worked, there were 'standard' lab passwords for things like root, administrative access to consoles, switches, etc. These are simple, easy to remember, and shared verbally with anyone who needed them. In general, if you could physically get into the lab, you were authorized to have these passwords.

In the manufacturing facility, new systems were built and configured for customers. The customer got to choose all the passwords, and they were printed on a set of forms that were attached to the rack with the systems. Remote access was provided as required, and the passwords were sent in an e-mail, or given over the phone. It was fully expected that the customer would change these passwords as soon as the system was delivered to them.

For the IT & Production labs, almost no one had root access. Almost everyone did have sudo access with somewhere between no limits and only the ability to mount virtual filesystems...depending on the person and the system. It was very rare to get sudo access to launch a shell as root. This left a very clear log trail of all the commands you ran as root. That log was used to tar & feather more than one person over the years.

At a help desk / support role I had many years ago, each tool expert picked their own administrative passwords. These were recorded in an envelop that was locked in a safe in the machine room. If someone needed admin access, they could open the envelop, read the password, and note in the log that they knew the password and then re-seal the password in the envelop. It was up to the tool owner to decide if the password needed to be changed. This system was used for more than 5 years...and in one case actually helped the project to survive the "bus test" (heart attack) for one team member.

Different standards for different kinds of systems and labs. That is reasonable. I find that when passwords need to be shard, it is best if the password is simple, short, and communicated verbally (either in person or over the phone). I find that the only password that should never be shared is the one for my personal account. Any root/admin/tool specific passwords should be backed up in at least one other head...if not recorded in some manner.