What's the best way to share passwords and credentials from the business's various accounts in a secure manner?

For example, email doesn't work because if someone gets into one of your employee's email accounts, then they'll have access to all your company's accounts.

  • 1
    I'd love to keep this question on our site, but I think you would be best served on the IT Security Stack Exchange site. I'd be doing you a disservice if I didn't send you their way - they are the experts, so I'm migrating it over for you. Jun 25 '11 at 20:14
  • It would help to describe: what resources you are trying to access/control access to, who you want to share with (are they all your employees?), why you are sharing (in case Alice is sick), and the value of the things you are protecting (helps identify how much security you need).
    – this.josh
    Jun 26 '11 at 8:12

I use 1password for this you can have a shared account which you sync via an exrypted file shared by Dropbox


I assume what you're looking to achieve here is a scenario where you have something like support@mycompany.com or maybe if you're a very early stage company mail@company.com.

I would honestly suggest that the best approach is not to share passwords at all. For most hosting providers, basic email is not that expensive until you want to scale to having gigabyte accounts etc. I would give each employee their own email address. You can do one of two things - make your generic accounts (where any employee could respond to the query) either inboxes (not in my opinion the best way forward) you all have access to (be sure you know how to recover the password in the event of a disgruntled employee changing it) or you could set that account up to forward the email to all the necessary employees. If you're a small team, that might do for coordinating replies.

The company I work for doesn't actually use email for support. We give our customers some access to our support ticket system (see this list of ticket systems) although we could have configured email submission of tickets too. Either way, when our clients have an issue, they create a ticket and everyone can see them. We also get to assign these to people, so the right developer actually handles the query. If you're handling customer queries like this it might be as well to use such a system if you can as it not only negates the need for sharing inboxes, but allows you much better organisation of your enquiry responses. Hosting such a system isn't that expensive either.

Generally, the best approach to follow with access control is to only give people access to what they need. You are absolutely right to consider what happens if an attacker compromises the account, but what happens if the employee decides to do a little industrial espionage for a competitor? As a start-up your business needs careful protection. So there is a secondary issue to giving out accounts - getting them back again. Make sure you have in place two things:

  1. That you as the business owner have the ability to technically recover whatever you need to quickly. For example, access to your office server you can simply as an administrator disable the account, so you're covered.
  2. Or where that isn't possible, that a condition of getting your last pay-cheque from you is the hand-over of all company assets including arranging hand-over of all passwords like Administrator accounts, passwords to routers and network attached devices i.e. anything the user administers for you and that doesn't have an easy reset mechanism you can use. I would, if I were you, ensure this happens before the last day.

The last thing you want, as a business, for your employee who left because it didn't work out to change the root password on your web server and lock everybody out, especially if they leave a nice rude message on your home page and you have to wait for tech support from your hosting company to take it down.

I'm sure listening to "security types" sounds paranoid and scary, but the truth is, you don't need bank vault security here, just some sensible practises so that should an attacker or employee target you, you have some defensive measures in place such that your business keeps going and the damage is minor.

Edit: I realise you didn't say you are doing development specifically, but that doesn't prevent you using a small scale lite version of a CRM, either.


This may just be an awkward question, but I feel it would be lax not to ask why you want to share passwords, as this is.such a big nono in almost any environment. It breaches any sort of control over identifying who carried out an action, and would definitively fail you on most types of it audit.

There are usually alternatives.such as delegated roles etc which still allow you to track activity.

  • Yes, I think you are leading to Role Based Access Control. Where people are given access based on their role, not their individual identity.
    – this.josh
    Jun 26 '11 at 8:08
  • 1
    i agree that passwords aren't to be shared, however a lot of social media websites and SaaS based services don't allow multiple admin accounts, twitter is one that comes to mind. Jun 27 '11 at 17:58

it is hard to answer your question because there is very little information on details.

We are talking about employees here, so one has to keep in mind that there is a legal framework, an employment contract. So especially in small companies and startups trusting the employees is the most practical solution. How do you manage security-related OCD may be an interesting read.

It probably is a good starting point to define one person (perhaps with substitute if your startup is large enough) to be responsible for IT. It is common practice that the IT guys are trusted in small companies because this get impractical otherwise very quickly.

Then you should look into the concrete services which require authentication.

Let me give an examples:

You probably have an contact@exmaple.com email address that several people shall be able to access. Setting this up as a normal account, with a password shared between the employees responsible for it, is an easy solution. Simple solutions are good because they are easily understood.

If one of those employees leaves the company, it has to be changed. Another downside is that it is an other password people have to remember. In case of an incident you will have to fallback to ip-addresses when reading the log files because all employees in question share one account.

Many cooperate mail servers such as Microsoft Exchange allow sharing of postboxes with specific accounts. So the employees responsible for the contact-email-address can access it using their own account. This is obviously a preferable solution if it is offered by your email system.

Another example are access to servers. On Microsoft Windows servers it may be a good idea to set up a domain. This allows people to login with their domain account to various Microsoft based computers and you can define roles for each account/computer pair.

The problem still exists for the domain controller itself. But this one should be operated only by two people, so preventing the issues of complex combinations between people and servers.

For the administration of Unix servers sudo (man sudoers) is the equivalent because it allows people to execute commands with the permissions of another user.

To summarize: Trusting your employees is a practical solution. There are relatively simple solutions for all common services but each service needs to be looked at.


The best would be not to share passwords at all and to delegate access to shared accounts to individual accounts where this is required.

However since this is not possible in all cases the best solution I have seen is a password vault with automated password change:

  • You login to the vault with your credentials e.g. Windows login.
  • Checkout the password with a clear audit trail and reason. This should also include the support ticket or approval email etc which can later be matched mannerly in a random audit or automatically via a SIEM (approval, checkout and action log)
  • Perform the approved actions
  • Check the password back in (with default check back in e.g. 24 hours)
  • The software automatically changes the password on the system to a random value. Scripted change for applications etc that need to use this new password

This provides the properties of:

  • maintaining individual accountability
  • having a single well controlled account where it is more beneficial than multiple individual accounts e.g. system accounts, service accounts, shared mailboxes
  • immediate password change on check-in ensures the population that knows the shared password does not grow

There are a number of tools on that can do this. For a smaller company it can also be performed manually with emails and excel and scripts to generate the password that is not know by the person that is changing the password


The best answer is that you shouldn't share credentials, you should have separate credentials, specifically for audit purposes. So when something is changes, or removed, or a decision is made, it is clear which person made it, rather than everyone having access to a single login.

Beyond that, if you absolutely have to share credentials, sharing something like lastpass would likely work best.


I've had the same dilemma before. Since I currently work solo I haven't had to decide on a solution yet, but I have come across a service that is pretty close to what I want: Passpack. It might be what you're looking for too.

  • 2
    For reader convenience, and since external pages change all the time, could you summarize the capabilities of this system in the answer itself?
    – nealmcb
    Sep 9 '11 at 3:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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