How does a team of Systems Administrators share passwords securely?

What are best practices for sharing hundreds of passwords among a few people? These passwords protect mission critical data, and cannot ever be visible beyond a small team.

I would probably write a custom web-based solution hosted on a corporate intranet. (take a look at http://lastpass.com for inspiration, or to use it. Sharing passwords is one of its features, though it may not work for your volume.)

EDIT: Sure, best solution, don't share them. Storing cleartext passwords in any medium is dangerous, particularly when the purpose of storing them is to share them. There is a nearly infinite number of solutions, each bringing an associated peril. Why not put them on an encrypted disk image, burn that image to a single CD, put the CD into a safe that only one armed guard can open, and have authorized people present photo ID to have it unlocked?

The point is we don't really know your scenario. Why are you sharing hundreds of mission-critical passwords? Are they for your backoffice intranet, VPN, or are they customer passwords that you keep around in plaintext for some reason? Are all the people you need to share it with in the same installation? Would a physical transference like an encrypted CD or a printed table stored in a safe actually work? Or are your sysadmins spread over the globe, making electronic means of sharing them the only solution?

Best practice is not to share the passwords. Use tools like sudo to allow the users to get the access they need from their own account. If you have a few users, each should have their own accounts where needed. LDAP (Unix/Linux) and Active Directory are a good solution for granting access to multiple servers from a common database.

When it is necessary to have a written copy of a password, seal it in an envelope signed and dated across the seal. Change the password when it is used. When the password is changed seal it an a new envelope.

For passwords which really need to be shared, use one of the password tools like Keepass which can have their database on a network. Tools with clients for multiple platforms are better. Consider wether you need more than one database. Remember you need to really trust everyone who has access to this data.

We have gone with KeePass for this exact purpose. It's a great little program that stores all of your passwords in an encrypted database file. There are additional security features such as needing a key file along with the main password to access the passwords. This allows for multiple layers of security (separate the key file and the database), all the while keeping it convenient for everyone to work with all of the different passwords. For example, you can run the app and the key file off of a USB drive, but store the database on your network somewhere. That would require credentials for the network share, the main password, and the physical USB drive with the key file.

What are best practices for sharing hundreds of passwords among a few people?

Easy, this comes in two flavors:

1. You don't, plain and simple. If you choose to do this, you defer password authentication to an external trusted authority and control authentication from there.

2. You do, but in doing so, you have external access controls that have passwords or security tokens that are not recorded inside the system you use (i.e. the record of passwords is protected by another password that has limited availability). There are numerous problems with this.

These passwords protect mission critical data, and cannot ever be visible beyond a small team.

You should seriously consider a secure authentication service that integrates with a directory service to address the issue. The DS/AS combination creates a trusted "authority" that can act as an arbiter for all of your users and devices. User accounts can have their access abstracted away from the actual password used in authentication, making it easy to "disconnect" passwords from access policy. Control of passwords is by deactivation of the user's account; so if an admin leaves, you simply shut off their account, and their access is gone (because that person's password only grants access based on the validity of the DS/AS confirming the account valid).

This will only work when you are in an environment that allows your devices/programs to shunt their authentication requests to external sources, so it may not be a solution for you. If you have a significant percentage of devices/programs that can accommodate external authentication, then I would go ahead and do this, if just to consolidate several hundred passwords down to a manageable list of, say, a dozen. If you decide to go this route, there are several off-the-shelf, well-known and well-tested solutions to this.

• Active Directory. Probably the most well-known of the group, gives you Kerberos as an authentication option, and provides LDAP for basic DS.
• Samba/Winbind. Think of this as "Active Directory Light", you don't get all of AD's features but rather an older model based on NT4 (think LANMAN hash). This will be supplanted with Samba 4's AD integration and will probably "go away".
• Novell Directory Services. I don't know enough about it to recommend it, but I know it still exists. A lot of government entities still run NDS, so if you're doing work in that "sector" it will be of interest to you. Novell recently ported NDS to run as a Linux service, but I don't know if that's still an active product (circa 2005).
• LDAP + Kerberos. This is basically "home grown" Active Directory, minus all the "nice features". However, they are also known components with a stable, matured code base, so integration of these service(s) is usually the extent of "customization" needed to make things work.
• SSH Keys + (insert system administration program here, probably puppet). Only useful where you have SSH across the board and all devices are accessed in this manner. Keys can be handed out and revoked as needed, and passwords become "irrelevant" as the SSH key grants access. Using a system like puppet allows you to update hundreds of machines by issuing commands en-masse to add/revoke SSH keys.
• Some combination of the above.

There is also a question of how much security you need. You didn't specify if by "mission critical" you mean that nuclear warheads may rain down upon cities, or if "mission critical" means that the latest shipment of Furbies won't make it into town. It would really help if there was something that described a risk/threat assessment.