We have various passwords that need to be known to more than one person in our company. For example, the admin password to our internet routers, the password for our web-host, and also a few "non-IT" passwords like safe codes.

Currently, we use an ad hoc system of "standard passwords" for low-value systems, and verbal sharing of passwords for more important/potentially damaging systems. I think most people would agree that this is not a good system.

What we would like is a software solution for storing "shared" passwords, with access for each limited to the people who actually need it. Ideally, this would prompt, or enforce, periodic password changes. It should also be able to indicate who has access to a particular password (e.g., who knows the root password for server XYZ?)

Can you suggest any software solutions for storing and sharing passwords? Is there anything particular to be wary of?

What is the common practise in small-medium sized companies for this?


19 Answers 19


I face this problem every time I go to a new startup. First thing I do is make a couple of "Password safes" with a program like this one (or one of its derivatives):


Set strong combinations and throw them up on a network share. Segment by area of responsibility... central infrastructure, production servers, dev/QA, etc.

Once there's enough momentum, and assuming I have the proper Windows environment dependencies, I like to move everyone to this:


It has features for both shared and personal credentials.

  • Is there a linux or mac program that can read passwordsafe files? It would be nice to have a good solution for an environment where people use various operating systems. The best I've found so far is gpg encrypted text files.
    – Mark
    Commented Jun 23, 2009 at 3:06
  • Absolutely: passwordsafe.sourceforge.net/relatedprojects.shtml Commented Jun 23, 2009 at 5:35
  • I checked out Passwordstate but it seems pretty limited compared to other paid for solutions.For one thing, password lookups are not auditable. However this should be available in the next release.
    – Sergei
    Commented Jul 20, 2009 at 13:05
  • Looks like Passwordstate has reasonable auditing features now. clickstudios.com.au/about/compliance-reporting.html
    – Nic
    Commented Feb 10, 2012 at 19:05

Not to be forgotten is the need to be able to revoke passwords if an employee leaves/is fired. There have been several cases noted in popular media of employees being fired and 'getting back' at their company using passwords that were still active after they left.

This is typically 2 parts:

  1. Knowing all the passwords that need to be changed (otherwise you default to all which is tedious)
  2. Manually changing them or automating the process with a tool or script.

Another important factor is ensuring that password policy is followed when the changes are made - e.g. how do you know that the same password was not used on multiple accounts or that a weak password was not used?

  • 14
    Just as an observation, I'd upvote this as a comment, but not as an answer, since it doesn't address the question. Still a good point. Commented May 20, 2009 at 13:29

I work in a small IT shop and we've been using Secret Server for the past year to manage our passwords for our network devices and client needs.

They offer an "install edition" or an online/hosted edition. We use the hosted edition for less than $100/yr (5 users) and can access this password information securely via web browser anywhere we go. If you're really worried about security, install it on your own server and only access it via LAN or VPN.

Additionally, my favorite "personal" web-based password manager now offers a "business edition" - PassPack.

I'm not sure how it performs in this scenario versus Secret Server but either solution ought to be much more versatile and secure than scraps of paper, desktop apps or (gasp) remembering things in your head. For the "single point of failure" concern, either of these products allow easy export to CSV.


I've been using LastPass for a while now and love it. I spent a bit of time researching this question in last year and I liked how LastPass had done it.

  • All info is stored on their site (and a local copy) in an encrypted bundle that only you have the password to decrypt
  • All passwords are shareable and revocable, you can even share them without giving access to the password itself (for web logins)
  • Plugins for the major browsers
  • Lots of other features

I second Adam's recommendation of PasswordSafe, with the data on a network folder. I have two considerations in this area. One is having a single version, so that all who need the data are getting the current data.

1- PasswordSafe uses a standardized format for the file, so there are other solutions which can read it, including KeePass.

2- Put the password file on a secure share, and have a nightly script which copies it to a couple of locations on the network. Perhaps copy it to a share on another server (off-site if possible) and to a USB drive left in the server. You want the file at least one place where it isn't protected by a password that it is storing!

3- Store the installer (or executable version of the program) in the same spots as the key file, so that you can get at it quickly if needed.

4- Have people open the file READ-ONLY, unless they have to make a change.

5- If necessary, you can create multiple password files, one for the credentials that everyone on the team needs, and one for the credentials for the really sensitive things.

I would not recommend moving to a web-based solution. An internally hosted solution could be OK, but it seems like a lot of trouble. I am also concerned about it being a single point-of-failure.


I share responsibility for quite a few systems with employees of one of my clients. We have agreed to use a password scheme for the most often used accounts. Other passwords are stored in a paper-based list of (number,password) pairs maintained by the client's Chief of IT. The usernames and hosts are stored in a easily accessible database. Passwords are handed out on a need-to-know basis.


Common practice in small-medium companies:

Three places I have worked in have used separate documents to detail passwords for different systems. One document for the routers and firewalls, another for access to the servers, and one for developers (e.g. login details for database connections). Access to applications tend not to be documented (I assume because for most you login as yourself with admin rights).

The network admin only sees the routers password document, and the individuals who have access to this document are listed in this file. Their terms of employment state that logins and passwords they have access to are private and not to be shared with others. Similar for systems admin and the developers.

Reality is sometimes the password gets shared, but you can identify who needs to know (and why) and change what needs to be changed. It worked well in a (software) company of 50 employees.


For seldom used passwords such as local admin accounts on servers, the router and firewall passwords and the like at my last job, a shop of about 50 or so, only the sysadmin actually knew the passwords. They were written down on a piece of paper in an envelope. There were I believe three envelopes which were sealed and signed by the Boss, the SysAdmin and the Head Programmer. Each individual had a copy of the documents. In the event the passwords were used we changed them and made new envelopes.

In my current job, at a much bigger organization we have 15 sysadmins alone, and a couple thousand users we have a method for calculating passwords based on a servers name. This includes a known prefix and a hash method that is simple enough to do on paper. When passwords need changing because someone leaves or whatnot we change the prefix or the hash or both. That way while I don't know the password to every machine or device around me I could calculate it if I needed it for some reason.

  • neat idea, can you please provide an example of such an easy calculable hash method? Commented Jun 16, 2009 at 21:49
  • You could use ROT aka cesar cipher, but using a randomly selected number between 1 and 26 for the offset. For example if your server was named fileserver2 and the prefix was Le84D and the offset was 18 the password would be Le84Dxadwkwjnwj20 Commented Jun 17, 2009 at 3:12

There's a Lifehacker post from today about Passpack, it might be worth a look.


I've had the same problem before. I ended up building a system to handle this myself. It stored the username and password in a highly encrypted form within a database with a Web Interface which would allow you to enter the account info, and set the security on it so that only the correct people or groups could access the data.

It didn't prompt for when it was time to change the passwords as services on dozens of servers used the same login and changes to passwords had to be setup well in advance.

I built it with a full auditing feature so that every time an employee looked at a logon it was logged so that we could dump the audit log to Excel for the SOX auditors.


Use GPG with the Symmetric option to encrypt a text file with all the passwords in it. Then all you need to do is provide the one pass-phrase to other admins. When an admin leaves the company, then just re-encrypt the text file with a new pass-phrase.

  • ... and change all passwords contained within, right? Commented Jul 5, 2013 at 16:28

Centrify has been working for me.


Wow, good thread! Nobody's mentioned my preferred solution (except in passing), so I'll give a shout-out to KeePass. Nicely extendable, with password-, key- or AD-based authentication. Does the job nicely for us.


For accessing servers:

Provide access to one server and use it as a jumpbox and manage the accounts on the jump box. Any one assumed to be trusted to the jumpbox is trusted to the remote resource. This way everyone has their own password and the password on the server for the particular account can be kept secret.

For accessing other resources:

Limit access to only essential personnel. Make sure to manage a list of trusted users. Change the password every 90 days and update the list of trusted users. Give people notice of the pending change 15, 7, and 1 day in advance. Only distribute the password to managers and allow them to determine who needs access. Use utilities to log access and regularly let users know they are closely monitored systems. Any funny business on the servers should be a known terminable offense.


I know this isn't exactly the answer you want but in my place of work its exactly the same, trusted members of staff are given the relevant passwords, passwords are not shared amongst devices and they are not written down. The system tends to work quite well as administration of devices is usually the responsibility of only a couple of members of staff. We also have a very good staff retention so trust can be built up over a long period of time.


You might want to use some sort of password vault software - that way you can give authorized users their own access to it and make sure the information does not leak by people leaving notes around. A good one probably doesn't even display the password, just drops it into the clipboard for cut'n paste.


We have a system like the President and the Bomb - two people each know half of the password. That way you'll never get a situation where a single rogue admin goes off and makes unapproved changes on their own.

  • Interesting... but not very practical for the PIN for the company credit card ;-)
    – Stewart
    Commented Jun 1, 2009 at 8:23
  • This is pretty interesting. There are many instances when my coworker (with the other half of the pw) and I arent together...but I do like this idea.
    – cop1152
    Commented Jun 1, 2009 at 11:56
  • 1
    Now you have turned a single point of failure into a dual point of failure. This doubles the odds that the password will be lost. Plus, it is completely impractical - I would never be able to get anything done if I knew only half of every admin password. Commented Jun 16, 2009 at 22:30
  • I do hope you don't mean you use generic admin accounts... no audit trail. Commented Jun 16, 2009 at 22:50

I work in a IT company, we have many clients, normally we troulbeshoot the problem remotely. We use ssh to login to troubleshoot. We have added one machine ssh-key to all our clients machines, So that it will be helpfull to other to login & troubleshoot the problems, if i'm not there.But the machine which we are using to login to clients macine its highly secured. If you want to have good passwords better use numbers and extra character.

To add ssh keys the following :

1.ssh-keygen -t dsa (To get ssh keys on .ssh/id_dsa.pub

  1. scp .ssh/id_dsa.pub root@remote:~/tmp

  2. On remote machine

cat >> /tmp/id_dsa.pub .ssh/authorized_keys2

Try to login to remove macine, from another console... :) happy sshhhhhh


Refuse to use systems that require a password. Any server must authenticate with SSH keys, any website with OpenID. Run an OpenID provider inside the firewall.

Obviously, this scenario implies all of your systems are accessible via SSH or HTTP, but it works for us.

  • I don't see how that works for routers, safe codes, credit card PINs, etc.
    – Stewart
    Commented Jun 23, 2009 at 19:26
  • "Refuse to use systems that require a password" - there are things like PTB so 'refuse' does not always work...
    – Sergei
    Commented Jul 20, 2009 at 13:06

Not the answer you're looking for? Browse other questions tagged .