Ask HN: How do you manage shared company passwords?
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/
64 comments
[ 3.1 ms ] story [ 123 ms ] threadInside engineering, we have been experimenting with a shared keepass db that we move between machines directly using git.
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.
It works in small groups (we're three guys using it, two more frequently)
Although I would probably still suggest a solution that allows more granular access controls and doesn't require everyone to share the same password for logging in.
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.
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.
Actually - I am going to stop guessing - how do you arrange keys and decryption please?
You can now do more things, like password protect the data, provide access to specific users, and perform a 'server assisted' decryption, which allows you to provide the private key without needing a gpg client.
I haven't personally worked on this plugin, so I might not have the details perfectly correct, but that is more or less how it works :)
[edit]
I forgot to mention, the encryption keys are uploaded by the admin, so a user is able to select from a list of keys to encrypt with when they upload the data. That might not have been clear before.
As an aside, are you aware of what progress has or has not been made in GPG as part of a browser API? I am not sure if thats your area
cheers
There are two main types of security provided by the plugin, gpg key pair encryption and user access control.
The user access control is only as good as Confluence security, except that you can additionally ask for a password.
The gpg encryption is as good as your private key management. There is a new option that allows users to decrypt without installing gpg on their local machine, however they still require the private key and passphrase.
With regards to gpg as a browser api, I am not sure what progress has been made. For this application, if you use the in-browser decryption, it appears that the decryption is done server side. I'm not sure what the security implications of that would be, although I would want to be using a secured connection at the least.
We now use http://www.passpack.com/ to easily share passwords and other credentials with my staff.
A good solution would also be able to manage private SSH keys as well
https://github.com/comotion/cpm/wiki/Revision-control
Assuming you've all the public keys in your keychain, then for each key you pass "-r <email>" for the encryption, like "gpg -e -r foo@bar.com -r baz@bar.com plain.txt", and for decryption you do something like "gpg --output plain.txt -d plain.txt.gpg".
[0]: http://security.stackexchange.com/questions/8245/gpg-file-si...
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.
"Your password never leaves your phone or computer and is not stored anywhere. Encryption occurs locally. You are the only one that can decrypt your data!"
square with
"Anywhere, anytime access. Access on the phone, web or desktop. All apps work in offline mode & auto sync when connected."
If they provide a web interface, they'll probably get access to my key at least temporarily (unless they decrypt in JavaScript and I trust them to not hijack this). GPG + Dropbox seems a little less convenient, but significantly safer since I have full control over the encryption process, especially in view of the fact that the US seems to be keen on listening in on cloud data of non-US citizens.
With no-compromise security in place, and with the incredible convenience the app affords, it is leaps and bounds better than home brewed solutions like GPG + Dropbox (which I have used for many years prior to switching to Strongbox).
I have found Strongbox so awesome, that I wanted a Terminal/command-line "Strongbox reader", so I recently wrote a Ruby gem and command-line interface for decrypting and reading Strongbox files:
https://github.com/abatko/strongboxio
Just try Strongbox, and I'm sure you'll be quickly impressed. Besides the obvious conveniences, including box sharing, it is possible to transfer ownership (e.g. you start a box, and pass its ownership on to your client). Also, there is an amazing feature planned that will bring cloud password storage to the next level.
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.
In any case, once we sign off on a project, the client normally like to set up their own usernames and passwords for admin accounts, it gives them a sense of control.
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.
mc ds and com - but it would not be obvious from the outset how to calculate these nor that we were even using a scheme.
So assuming the shared portion of the password is compromised I assume it would be 64 bits of entropy? (I'm not overly experienced with calculating that so I assumed you did 2 x 2 ^ numberofcharacters, whereas in this case we have 6 characters, doubling the entropy.)
While this may not be a massive amount, bare in mind these are temporary passwords and last only a week or two before we sign off on a project and the client has access.
1. As you say the To01n would be static and I would assume that this would be the same in both
2. If both sites are .com then I'll spot the com in both and so I'll end up assuming there are 4 characters to attack. And they appear to be lowercase.
3. Or they are not both .com and assuming I'm not smart I think there are 7 or 8 characters to attack (all lowercase).
In case #2 picking 4 characters from lowercase ASCII has an bit strength of 4.7 bits per character and so 18 bits. Very weak.
In case #3 picking 8 characters from lowercase ASCII has a bit strength of 38 bits. Still weak.
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
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.
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.
[1]: https://github.com/github/swordfish