Ask HN: How do you manage shared company passwords?

[culturestate]

I'm talking about things like client FTP logins and apps / services that don't provide multiuser functionality.

We've used and/or evaluated everything from a shared KeePass db, to commercial apps like Password Manager Pro[1], Passwords Max for Groups[2], and Passpack[3] to a protected Google Docs sheet and an Excel file in Dropbox.

The KeePass solution seems to be the "best", though there are still some caveats - is there a best practice here? Do most small engineering groups roll their own?

1. http://www.manageengine.com/products/passwordmanagerpro/ 2. http://www.authord.com/PP/ppgroups.htm 2. http://www.passpack.com/en/home/

[statik]

I use LastPass Enterprise edition, everyone at the company has an account and we share some role account passwords via shared folder in LastPass.

Inside engineering, we have been experimenting with a shared keepass db that we move between machines directly using git.

[shanelja]

We simply don't need to - we use a procedural password which any of our employees can easily emulate but which still provides enough entropy.

It goes something like this (of course, this is slightly different):

(First 2 letters of domain name) + (To01n) + (TLD) + (Last two letters of domain name)

So, for instance, www.mcondalds.com would be:

mc + To01n + com + ds || mcTo01ncomds

This appears random to the client but is easy for us to work out once you've done it a couple of times, but of course there are exceptions:

Hosted on Localhost TLD: loc

.co.uk TLD: couk

Once you adapt your company to a procedure like this is becomes simple and quick to log in to client sites, but also saves you the overhead in time of managing a large spreadsheet or application for it.

[jgrahamc]

Your scheme doesn't appear to provide any entropy at all (or at least hardly any). The only unknown part of is the To01n which if compromised causes the entire scheme to fail (assuming you accept Kerckhoffs's principle). If it's widely known in the company then it's an 'open secret'.

If the unknown part is not compromised then I have to crack 5 characters. Assuming, best case, this is taken from the entire printable ASCII set then there are 32 bits of entropy. That's very weak.

[ScottWhigham]

I have a hard time believing that you use this system everywhere in your company. Wouldn't any employee then be able to guess the password to any company service? I'd be able to guess the company PayPal account, the company Stripe account, the company bank account, etc. I just don't believe that a real, legitimate company that is able to have enough success to have hired employees would've done something like this across the board.

[jere]

Wouldn't this mean ex-employees would know your password scheme indefinitely?

[deanclatworthy]

Also the weakness here is that if two websites with weak password security are compromised (let's not forget recent history) your company password naming scheme will be completely obvious at first glance, assuming you use the same email login.

[eumenides1]

KeePass + some kind of bidirectional file syncing service.

Personally, I use dropbox to sync personal passwords to my work computer.

Professionally, I use OpenText Tempo Box. I work for Open Text, I don't personally work on the product, but do like it. The Tempo Box product has similar features to dropbox, but it is for those that need to keep their data within corporate controlled servers.

Despite the service you choose the most important lessons learned are: 1. People need to close keepass every night. So if new passwords arrive, they will get them. (People tend to leave the application running) 2. People need to be taught to use a keepass and encouraged to use it! People are afraid to update the entries and things fall out of date. 3. Sync first, then update! 4. Please use a title naming convention. We didn't and things got messy. We have many instances of the same application. Naming is very important. 5. Auto-type is nice, please configure it and teach everyone to use it. (There are some applications it refuses to work on: Remote Desktop)

I hope this helps. Internally, we gotta do some of the above and clean it up. But overall it's a working out pretty well for us. We have a global team that spans multiple offices and timezones. If anyone has a better solution, I'm all ears.

edited for spacing and glaring grammer errors

[Cogito]

Our company is a services company built around the Atlassian suite of tools. Part of what we do is write plugins for those applications.

We developed a plugin called Security and Encryption Plugin (previously Vault) for Confluence, that allows you to protect any piece of text with GPG encryption.

Any shared credentials get stored in the Vault on the corresponding client's spot in the Confluence wiki, where we store all other data about that client as well.

The private key and pass are shared separately. Once you have the key and pass set up with whatever you use for gpg decoding it works pretty well.

We have a couple of different 'security levels' which are just key pairs where not everyone in the company has access to the private key.

The plugin is paid, but it is supported and has new features added from time to time (for example, you can now share things with specific users, or users who have a password, as opposed to just via gpg private key). If you are already using Confluence it is worth looking at.

[lifeisstillgood]

Thats fascinating - does it need gpg on the client machines - or (and this is a guess) if you are logged in as Fred, does the server store Fred's private Key?

Actually - I am going to stop guessing - how do you arrange keys and decryption please?

[davidbanham]

We've been using PassPack for around a year now and it's been great. The only gotcha is that if I store a password and share it with you, you can't then share it with someone else.

[woodrow]

https://github.com/gdb/password-vault, which provides GPG encryption of data at rest on the server, and only stores data (encrypted or not) transiently on the client to mitigate the effects of a stolen machine.

[agranig]

We use plain GPG-encrypted files stored in our version control system (git/svn). The files get encrypted with all the public keys of the users who have access to these files, and can be decrypted with their private keys then. Not perfect, but works.

[hamburglar]

We do this too. The trick is making sure everyone keeps everyone else's public keys up to date and signed in their clients, because if you edit the file and re-encrypt it for everyone else to read, it's easy to overlook that GPG ignored one of the recipients due to you not having their key signed, etc.

None of us are fluent enough in GPG practices to do this stuff off the top of our heads, though, so our management of these files involves a lot of rote "here's how to re-encrypt the file" or "here's how to import the new guy's key" instructions. It's pretty clunky.

[maayank]

you mean you have for N users N copies of the file, each encrypted with a different key, or one file that is encrypted with N keys and then you need N keys to decode?

[qixxiq]

I recently posted https://password.ly here, and while it got a huge amount of hate for having users submit their passwords to my server, the actual concept is really useful. The command line client also never needs to send the password (unless you sync, and I'm trying to plan updates so that isn't required.)

Basically it uses bcrypt with the site name in the salt, so you get a completely unique password that can't be reversed for each site. Each employee will get access to our master password which can be changed on a semi-regular basis and then we keep a tab-completeable list of all seperate site names that were used.

[danielsamuels]

We use a Google Docs spreadsheet on our internal Google Apps account.

[tallanvor]

There isn't a perfect solution, but LastPass Entrprise or a similar service is probably the closest you're going to get.

KeePass is great, but it's a single user solution. --Even I have to be careful about forgetting to save the database after adding a new entry at work and then going home and adding something else there.

You shouldn't even be entertaining the idea of a Google Docs sheet or an Excel file in Dropbox when you're dealing with client passwords. That's just asking for trouble.

[robin_reala]

LastPass Enterprise is working well enough for our organisation. The only thing I dislike about it is that I have a personal LastPass account and can’t keep them both logged in at the same time through the browser plugin.

[Ecio78]

We use KeePass as a multi-user solution: the kdb file is on a network share (with relevant ACLs). The only thing you have to take into account is that you dont have to leave it opened on your computer, so the typical use is: Open / Read (or Write) Password / Close it.

It works in small groups (we're three guys using it, two more frequently)

[SeanKilleen]

I used PassPack (http://www.passpack.com/en/home/) for a while and that seems more than sufficient for sharing passwords providing you don't mind that your encrypted data lives on another server. Unfortunately they don't have a white-label version for use internally. I spoke with the leadership there about it but it seems the idea was abruptly dismissed during a leadership change a while back.

[jiggy2011]

If you are using plain FTP for something then it is safe to assume that security is not a priority anyway, so a shared .txt file with the password in should suffice.

[culturestate]

Thank you, but by "client FTP" I mean an FTP server provided by a client for data exchange as part of their internal protocols. It's not always possible for us to bend clients' IT policies to our own desires.

[onemorepassword]

We're currently using 1Password with the database on Dropbox. Which is extra convenient since it allows read-only access via Dropbox without needing the client.

The company used KeePass before, but that created a single point of failure for access and maintenance.

However, if I had to choose now I might go with LastPass (which I use privately), although I'm still somewhat uneasy about depending on an online service.

[wlk]

It's usually the best to avoid shared passwords:) When possible we try to use either key-based authentication or create separate accounts with the same permissions.

But when we have to do something like that, we just send passwords to each other in a encrypted way (using keys or over ssh session with shared screen). And everyone has his or hers own way of saving passwords locally.

[KMag]

As far as FTP passwords, publish them in big blinking lights out in front of your office. Make absolutely sure each FTP password is isolated to a single site, and not reused for any other purpose.

As alternatives, kerberized FTP will allow you to generate keytabs and many scp setups have public key auth enabled.

[davidw]

http://73primenumbers.com/ has a smash hit "pencil and paper" app that combined with the 'secure closet' technology, might be an appropriate solution if you're reasonably sure you'll only need to access the shared resource from the office.

[jos3000]

I wrote a custom script for Google Spreadsheets to encode our passwords using AES with on master password shared between me and my business partner.

We now use http://www.passpack.com/ to easily share passwords and other credentials with my staff.

[jimktrains2]

I wrote this https://github.com/jimktrains/polygonus to allow passwords to be encrypted by gpg and other possible information to be stored in the section with the password (config for a cert).

[captn3m0]

Github is working on an app called Swordfish[1] for some time. It uses JS crypto to make sure that even if your server is pwned, your passwords remain safe.

[1]: https://github.com/github/swordfish

[eduardordm]

I'm laughing because as I write this I look to a board in front of me and there is a password of a router we use to manage EC2 connectivity written on it even though we signed for a passpack-like service.

Maybe we are trying to solve the wrong problem :D