Don't Share Passwords. But If You Do, Do It This Way.

Posted

You don't need me to tell you that Password Sharing is Bad; if you're reading this, you probably already know that. Unfortunately, in many cases it's inevitable. I've learned a few things about sane ways to share passwords, both first-hand at the companies I've worked at and in conversations with our customers. Here are a few tips for managing shared secrets at your company.

Prefer Individual Accounts

Some services we use and love only support a single username and password (I'm looking at you, Mailchimp) and you have no choice but to share; but for many services, it's possible to set up one login for each person, although it may take some extra effort. Amazon Web Services (AWS) has an extensive but complicated set of account sharing policies through their Identity and Access Management (IAM) service. This can involve additional work to set up, but the up-front effort is worth it, especially for such a critical system. AWS provides a guide on their blog.

Most companies these days use an official Twitter account. There's no built-in support for sharing these accounts, but there are third-party workarounds. Services like CoTweet make it simple and secure for many people on your team to operate the same Twitter handle (as well as many other features to make Twitter more usable for businesses) – this added security is worth the small expense.

Centralize Your Shared Passwords

When you do have to share passwords, you should do so in a uniform way. Adopt and communicate a simple password sharing policy to your team – any shared secrets need to be shared in the same way, and the sharing should be public. This policy is less about security and more about auditability: when your company grows to the point where securing shared accounts becomes crucial, you'll already know where all the keys are and you'll spend less time digging around. The key is to avoid untraceable, point-to-point sharing via emails, IMs, or sticky notes; always share visibly.

There are myriad ways to share passwords among a team - just pick one and stick to it. My team uses Google Apps, and I'm a big fan of just having a Google document or spreadsheet that has a master list of all the usernames and passwords that must be shared. Invite everyone who needs access to that document. It's easy to break this down into sub-documents over time if necessary (i.e. one document each for engineering, sales, and HR).

A slightly more sophisticated approach is to use a dedicated password sharing application along with something like Dropbox to mirror changes. I've used PasswordSafe along with Dropbox for years to track my personal passwords; this approach works just as well for a team. If you want password sharing integrated in to your browser, you can move to something like LastPass or 1Password.

Whatever solution you use, make sure you have backups! Google Docs automatically keep track of old versions, and Dropbox does as well. You don't want to risk one individual accidentally wiping out the password list, so make sure you have old versions around. And don't forget to also record other non-password secrets (i.e. answers to secret questions) in your system as well.

Use a different password for each service

You'll need a master password for something like 1Password or PasswordSafe, but that should be the only truly "shared" password you use. For each individual account, generate a long, random password that is used only for that service. Dedicated password management tools will be able to do this for you. If you're using a document, use an offline password generator like apg to create each password.

Set up a shared email address

While every service should have its own password, you should use the same email address for any shared accounts. If your company is example.com, set up something like shared-accounts@example.com and use that email to sign up to services. This standardization makes things more uniform, clearly calls out shared accounts versus individual accounts, and avoids the risk of a shared account being attached to a person's inbox, since that person will eventually leave. In the event that a password is lost, you also have a uniform way to reset a password (since everyone can get to the shared inbox).

You'll probably want this to be a real account on something like Google Apps, and not just a mailing list, for two reasons: you can use it to sign in for systems that support log in with Google Apps, and you may need to be able to send emails from this address, if you need to communicate with customer support for a service.

Share eagerly and over-communicate

When you sign up for a system that only allows one account per company or team, be sure to get those credentials in to the shared document immediately. Often there will be one primary user of a system or service, and account sharing is infrequent. If that system is critical to your business, you're running the risk that the primary user won't be around when they are most needed. Any number of engineering teams can tell you about the time they needed access to the master DNS account at 3AM, and the person who set it up was nowhere to be found.

Above all, over-communicate with your team about which shared systems you use to do your job and how to access them. If you have a team chat room or mailing list, use it to ping the appropriate people when you add or change a shared credential. Putting a policy in place for secure and simple sharing takes very little work up front and will pay dividends as your business grows.