Ask HN: How do you manage shared company passwords?

https://news.ycombinator.com/item?id=5133263

by culturestate • 13 years ago

36 64 13 years ago

news.ycombinator.com

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• 13 years ago

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.

davidw• 13 years ago

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.

tallanvor2• 13 years ago

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.

Ecio782• 13 years ago

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)

estel3• 13 years ago

We do something similar, but with relatively few users using Keepass 2, there aren't really any issues with leaving it open on multiple machines. Is there an issue besides synchronisation?

robin_reala2• 13 years ago

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.

robin_reala2• 13 years ago

Of course, today a colleague pointed out that from within your enterprise account you can ‘link your personal account’ from the let sidebar. That was my last gripe really (apart from the front-end code needing an overhaul).

wlk• 13 years ago

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.

Cogito3• 13 years ago

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.

lifeisstillgood2• 13 years ago

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?

Cogito3• 13 years ago

The 'traditional' method requires gpg on the client machine. The vault was just a way of uploading text and having it encrypted on the server automatically. The user was required to download the encrypted data and then decode it themselves.

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.

danielsamuels• 13 years ago

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

endymi0n• 13 years ago

KeePass in Git is our way to go as well. You just have to get used for this repository to an immediate pull -> change -> push workflow, otherwise you'll have to merge binary files which gets messy.

denglish• 13 years ago

We've been using https://www.boxcryptor.com/ on top of Dropbox for passwords and other need-to-keep-very-secure data.

jos3000• 13 years ago

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.

raverbashing2• 13 years ago

I've ran into this problem, but most of the time the passwords were shared orally

A good solution would also be able to manage private SSH keys as well

KMag2• 13 years ago

For what purposes do users need to share private SSH keys? The trusted keys file can hold an arbitrary number of public keys.

raverbashing2• 13 years ago

Yeah, sharing is a bad example, it's more like passing keys (to be added) or passing control to another person that will log in and add new keys

pkhamre• 13 years ago

I'm using cpm[1] with revision control (git).

https://github.com/comotion/cpm/wiki/Revision-control

SeanKilleen• 13 years ago

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.

davidbanham• 13 years ago

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.

agranig2• 13 years ago

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.

maayank• 13 years ago

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?

agranig2• 13 years ago

You've one copy of the file, encrypted with N public keys. Each of the corresponding private keys can decrypt the files.

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".

haldean• 13 years ago

You can encrypt a file to N users in GPG with only one output file, and require only one of the corresponding private keys to decrypt. More information here [0]; TLDR, it encrypts with a symmetric key then includes the symmetric key encrypted with the public key of each recipient.

[0] http://security.stackexchange.com/questions/8245/gpg-file-si...

hamburglar• 13 years ago

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.

lflux• 13 years ago

Binder in the safe.

woodrow• 13 years ago

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.

abeh• 13 years ago

I have used http://www.strongbox.io/ - it allows you to create a 'box' of passwords or other data that is securely shared with other users.

anonymouz• 13 years ago

How does their claim:

"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.

abatz• 13 years ago

In all cases, including the web interface, the app is client-side. When you access the web interface, a Silverlight app is actually downloaded to your browser, so decryption and encryption is always done locally. Once a box has been modified, the box is encrypted locally, saved locally, and then it is uploaded over HTTPS to cloud storage.

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.

jiggy20112• 13 years ago

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• 13 years ago

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.

jiggy20112• 13 years ago

If you are using FTP without wrapping it in TLS then your password is being sent over the network & internet in plaintext so how secure the password is on your machine is probably a moot point.

shanelja6• 13 years ago

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.

jere• 13 years ago

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

shanelja6• 13 years ago

I suppose so, yes, but on the other hand, wouldn't it mean that every time an employee left, wouldn't you have to go through every single password (currently 436) and change them?

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.

deanclatworthy• 13 years ago

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.

shanelja6• 13 years ago

No, each website has a unique username for the admin system, thought these are normally just the company name.

jgrahamc3• 13 years ago

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.

shanelja6• 13 years ago

While that may be true, an attacker would not initially know the scheme, but with a list of passwords would instantly notice the To01n so I could argue that that is in fact the weakest part of this procedure, which leaves them with the 7 letters remaining:

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.

ScottWhigham• 13 years ago

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.

shanelja6• 13 years ago

You misunderstand, we use these passwords for client website logins for the admin accounts prior to the client changing them, as per the PayPal account, etc, that is taken care of by the Boss, IE, I don't have a clue what they are. Most likely his Gmail password.

eumenides1• 13 years ago

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

mweibel• 13 years ago

we use passpack - it's really easy to use, seems secure and nice

onemorepassword• 13 years ago

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.

jimktrains2• 13 years ago

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).

qixxiq• 13 years ago

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.

captn3m0• 13 years ago

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• 13 years ago

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

itsbenlee• 13 years ago

We built our own for our consultancy: http://www.youtube.com/watch?v=Qicebedl_X4

superchink• 13 years ago

Do you have plans to allow others to use this?

dguaraglia• 13 years ago

KeepPass + Dropbox. Not a 'great' solution, but it works provided you trust everyone to do the right thing (Dropbox, and your co-founders not being silly and sharing the file with the world.)

KMag2• 13 years ago

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.

pasbesoin• 13 years ago

This question was asked here on HN sometime in the last couple of months (I have a distinct memory of this), if you want to Google up that thread for its responses.

Ask HN: How do you manage shared company passwords?

Related Stories