Storing passwords

Published: 2009-09-23
Last Updated: 2009-09-23 23:59:11 UTC
by Mark Hofman (Version: 1)
46 comment(s)

I have a problem, no a challenge, for you all.  How do you store passwords that have to be shared between team members. 

I'm confident in saying that every IT environment has this problem.  You have passwords for service accounts, printers, switches, routers, firewalls, admin passwords for products, build passwords when building servers or desktops, etc, etc, etc.  Many of these can only be accessed through limited userid and can't be hooked into a radius Many of these don't need to be used often, but they do need to be recorded and in a typical IT environment there are likely to be a number of people that need these.  So how do you share them in a sane manner?

Some of the examples I've come across include the traditional word document or spreadsheet, sometimes it even has a password.  Other examples are databases, Lotus Notes, MS Access, Sharepoint pages, wiki pages, post-it notes, commercial tools, some are better solutions than others.  So I'd like to know what you do when faced with this issue?  Send some in and we'll share your experiences in an update.

UPDATE

Thank you all for contributing, the response has been excellent.  Most of the methods used have been reflected in the comments.  

Mike has one for the *nix users out there.   

"My preferred method is an encrypted file (using vi -C) read/write only by root on a system like a nis master, where you have to log in as you then using either pfexec or sudo to access the file.

This satisfies the theory that you need to have a user account on the correct system, the correct privs and know just one more password - this is reasonably straightforward.
One additional safeguard is using a version control system like the builtin (on Solaris) sccs to keep a good record."

Joost uses Keepass like many in the comments.  

"On a share only accessible by IT we have 2 keepass (http://keepass.info/) databases. Both are protected by a password and a keyfile (on a usb stick).

database 1 is for all passwords that are for the helpdesk, network- and systemadmins.
database 2 is only for network- and systemadmins."

Several people wrote in regarding the eDMZ product. 

Bryan mentions their own application:

"we used to have a commercial app, then we started having problems. So we built our own internal PHP-MySQL webapp. It is only accessible via HTTPS, and the database uses MySQL's built in AES encryption to store the password data encrypted. Users must enter a username, password, and encryption key to login. This does make the encryption key short, but it is never stored in the application itself.

It is a stand-alone webapp at the moment, but we are planning on having it connect to AD for authentication, and writing in permissions to limit user/group access to passwords.
"

A few readers also use the good old piece of paper and safe method, after all you don't really need to use these shared accounts often, if at all.  

Thank you all for your excellent contributions.   

Mark

 

Keywords:
46 comment(s)

Comments

I use Keepass on an encrypted USB drive
So, this is the big issue in theory you should never have to access these password and they should be stored in a safe. And all servicing should be done on a dlegated manner where each user uses his/her user/pwd combo.
However the reality is that this just isnot possible in some environments. My experience gambles on an effective SCM - security configuration manager where you store all the necessary security components (configs, accounts, etc) and log when confidential information is access such as passwords.
Keepass on a shared folder too...
But as FVTer wrote...when we grant access...we grant access to all password. We didn't found a suitable product for that
on the work front we use a ManageEngine's Password Manager Pro. Personally I use KeePass and am currently evaluating PassPack.
We manage our common admin passwords on an offline machine stored in a secure location. On that machine the passwords are stored in an encrypted database using an in-house application to manage it. Our admins plug in encrypted USB flash drives (that are secured with both a biometric ID and a password) which are automatically loaded with the DB data after they have authenticated. If someone snags one of the USB drives and fails authentication 3 times, the software starts a 30-pass wipe.
Take a look at Password Manager XP by CP Labs (http://www.cp-lab.com). It's a commercial app, , but inexpensive and we are very happy with it.

Highly encrypted.

support for multiple databases.

ability to access passwords databases from
multiple computers across the network.

adjustable user privileges per given database.

permissions can be set for folders or even individual records.

concurrent write access to a database for multiple users.

NT authentication support.

logging of all data changes.
as already mentioned, i'm used to have password safes for storing various account details. benefit in my point of view, u can use different "password databases" for different people/groups in a secure way. and with the right software u can also take them on a usb stick/cd for field or on-site service et al. (e.g. password safe, keepass)

if u don't need the mobility, i think a wiki/sharepoint site over https with appropriate user access rights (if supported) is also quite easy to use. but to be honest, i think, that such ways to "store" passwords is not that good - people tend just to print out the document in case they need it offline. and paper documents tend to get lost ;-)
I have done it two ways.
KeePass Database (encrypted) in a TrueCrypt Partition.

Apple's builtin KeyChain Access which KeyChain is protected by my main system password, then the individual keychain I setup for sensitive passwords has an additional password.
@UniAdmin - the usb stick itself sounds interessting; may you can provide some details about that?
We have a shared "sysadmin" keepassX database... On GetDropbox.com shared :)

Diary Archives