83

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.

4

13 Answers 13

14

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?

6
  • 52
    IMO Building your own security/encryption system is almost never the right approach to a problem.
    – Zoredache
    Jun 3, 2010 at 2:47
  • 2
    @Zoredache, That's a load of crap. Though, I do think web-based solution for hosting passwords is stupid - but he did msanford did say intranet. Still risky though. Same for all the other networked solutions.
    – d-_-b
    Jun 3, 2010 at 10:48
  • 2
    @Zoredache, the OP is not building a custom encryption system, it sounds like all he needs is a secure database. @sims I see nothing wrong with a well-designed web-based solution. The up-voted answer suggests precisely that (web-based != http; web-based = stored online). Admittedly, once I read over this question a second time, I agree that the basic model of sharing tonnes of passwords seems likely to be unnecessary, and that a better solution could be reached. But the OP hasn't given enough information for me to make that judgement…
    – msanford
    Jun 3, 2010 at 14:34
  • 2
    >@Zoredache, that's a load of crap.< Um, Sims, you're pretty much flying in the face of most encryption folks right off the bat. Designing encryption is hard, making it worthwhile encryption is harder still. schneier.com/essay-037.html Sometimes the lesser evil - the one you know - is the better choice, when confronted with the evil you don't know (i.e. a design that is untested, non-peer-reviewed, may have bugs, may have security holes, etc.) Jun 3, 2010 at 19:53
  • 1
    @Avery - designing a cryptographic system is difficult and should be left to the experts, yes. Using tried-and-tested tools, like GPG on a shared text file, or Keepass (which uses the .NET implementations of AES and SHA-256) is not designing your own system.
    – mfinni
    Jun 3, 2010 at 21:04
38

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.

5
  • +1 for unprivileged user accounts for admins with possible privilege escalation, on *nix servers i'd combine that with using only dsa/rsa certification for sshd. If you're doing stuff with graphical tools under linux you could also use a customized policykit configuration.
    – Aaron Tate
    Jun 3, 2010 at 0:25
  • 12
    This. Revoking access for users when they're using shared credentials is an absolute nightmare. Wherever possible, delegate access via a users unique account. There are always a few situations where a common password is unavoidable, but 'hundreds' of shared passwords screams critical design flaw. Jun 3, 2010 at 0:36
  • 4
    I'd agree with not typically sharing passwords, but there are lots of situations where it's necessary such as network devices with a single login, vendor sites where all the sysadmins use the same login for ordering, and SQL sa users or local admin passwords where necessary. That's why I think KeePass is best for this: it works on multiple platforms, allows for a good deal of security, and easily organizes hundreds of passwords.
    – Paul Kroon
    Jun 3, 2010 at 1:03
  • 2
    We have a variation on this, where we have root passwords written down but locked in a safe that only the systems team have keys to open. Our root passwords themselves are 16 characters long and are generated in such a way to be next-to impossible to remember. Yes, there's some insecurity there, but if someone breaks into the safe, I suspect we have bigger problems.
    – Frenchie
    Jun 3, 2010 at 3:04
  • 2
    Here's a real use-case scenario for our team: sharing passwords for web-based applications where they don't support multiple logins for a single account. So if more than one person in the team needs to be able to access that account, there needs to be a way to share the passwords for that account. Nov 30, 2012 at 18:56
11

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.

5
  • KeePass appears to support multiple platforms, a big win in my eyes (I work in a mixed-platform environment). The "auto-type" feature looks useful too. Jun 3, 2010 at 0:59
  • 2
    Stupid idea to keep passwords on the network.
    – d-_-b
    Jun 3, 2010 at 10:50
  • 1
    @Sims - then how do you share them? KeePass uses an encrypted file for the store. It's just a more-usable version of a GPG-encrypted text file on a Unix server that everyone has access to.
    – mfinni
    Jun 3, 2010 at 14:58
  • 1
    @Sims - I'd normally agree with you, but it gets to be a situation of security vs productivity. I wouldn't want to put the root password of a server in something like this, but the admin password of a Layer 2 switch that only has a single login is a good candidate for this. There's a point when it takes more work doing things the more secure way than it would to clean up after a security breach. Plus, on top of all the encryption, you'd have AD/NTFS security on the file, and a little obscurity by putting the file (which can be named anything) in a random location.
    – Paul Kroon
    Jun 3, 2010 at 17:08
  • I wasn't thinking of a Windows machine. But yeah, if you can only have one user for that switch, then I guess it would make sense. Otherwise as Bill says, say no for shared passwords, which was also my point about keys.
    – d-_-b
    Jun 3, 2010 at 22:01
5

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.

2

A few things:

  • As others have said, this is a bad idea. Use an LDAP, etc
  • If you are committed to doing this for whatever reason, at least consolidate the passwords. 100 unmanaged passwords means that you're not updating passwords.
  • Keep them on paper. Require that staff sign the paper in a different color ink to make it easier to determine whether a sheet was copied.
  • If you're on Unix, use S/KEY to generate one-time passwords. Store that somewhere safe.

You also need to go beyond the mechanical security measures of putting paper passwords in a safe or encrypting the passwords. Go read up on how organizations with mature security models secure keys and safe combinations. I don't recommend doing what you want to do, but if you do:

  • The folks who will use the passwords cannot control access to the passwords. A distinct group of people under a different management chain needs to control access to the safe, drawer, etc. If you have a finance group, they may be a candidate. Maybe the VP of marketing, etc.
  • There needs to be a written log when the safe is opened and someone takes possession of a password.
  • The password must get changed within 24 hours of being checked out.

Procedures like this are a pain in the neck, but will serve as an incentive for people to adopt more sane practices. If you don't do something like what I described, don't bother going through the motions of locking up the passwords, because you'll just get breached someday anyway.

2

I know this is an old question but I just recently came across a opensource web based solution called Corporate Vault that may be interesting to some. I haven't had a chance to try it out yet.

1

we use a program called Password Safe. it's nice and very secure, you can set the database on a networked drive and give everyone who needs it access and the password to the safe itself, which then stores all the usernames and passwords encrypted securely.

1

https://pypi.python.org/pypi/django-pstore/ uses per-user GPG encryption for shared passwords (and any other data you might like to share). The server never knows about any passwords, it only holds the encrypted data. Everyone uses their own private key to decrypt the shared secrets.

The system includes rights management: not everyone gets full access.

1

We use https://passwork.me as self-hosted solution. But you can store passwords in their cloud as well.

1
  • It is your product Iliya but it does look good. Apr 12, 2016 at 14:32
0

SPB Wallet is a good one we used to use PW safe by ghost but SPB wallet lets you sync to a network share and also sync to your iphone if you get the app. It also has a built in password generator and you can generate them from simple passwords to extremely complex passwords. You can also copy the password while the password is still asterisked out so if someone is looking you can copy it and paste it without anyone seeing the password. The PC app auto locks out once there is no activity for a defined period of time.

0

Another option is Azure Key Vault which securely stores your secrets and allows you to permission access to them programmatically, easily rotate your passwords, etc. No nice UI for it, but if you're fine with command-line access this is good.

0

Our best practice is to share as little as possible amount of passwords.

Therefore we for example: - use my.cnf in root home dir for passwords to the database - use ssh keys to login to servers and have one root password that is allowed only via console (so you must have physical/bmc access to the server) - use ldap everywhere possible (ssh, bmc, switches, redmine, ....)

However, there are few situations where we are not able to use this approach (such as root password). Then we use keepass on our shared storage, but we keep as little as 10 passwords there needed.

-1

Very good question. I'd be interested in other answers.

Here is what I do, but first I recommend using pre-shared keys where possible. I don't know if this is possible with Windows systems though.

Since the amount of passwords should be small (you are using keys where possible), I use an plain text file encrypted with gpg on a system that has no NIC. So (1) you need physical access and (2) a password.

edited for clarity

2
  • Keys? As in, USB Keys? Physical keys that open locks? Smart Card Keys? GPG Keys? Pass-phrase keys that only exist in the wetware in your head? Combinations of the above? Jun 3, 2010 at 20:05
  • Car keys! JK. To clarify, I mean ssh keys. Which is why I said it might not be possible to use pre-shared keys with windows.
    – d-_-b
    Jun 3, 2010 at 22:03

You must log in to answer this question.

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