
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.<p>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.<p>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?<p>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.

~~~
shanelja
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.

~~~
jgrahamc
Ignoring the fact that I usually go by Kerckhoff's Principle and would assume
that an attacker knows the scheme. Let's imagine the situation where two
passwords are compromised.

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.

~~~
shanelja
Thanks for the reply, would you be able to supply a decent link or a quick
explanation of how you calculate that? I'm more than happy to admit I'm wrong
when I am - the scheme is to make sure all client passwords are different,
though not in any way secure against an intelligent attacker - but I am keen
to learn more about this, so that as with every discussion on HN, I walk away
with a little more knowledge and a little less stupidity.

~~~
jgrahamc
<http://en.wikipedia.org/wiki/Password_strength>

------
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?

~~~
Cogito
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.

~~~
lifeisstillgood
So the security is essentially as strong as the Confluence User security?

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

~~~
Cogito
> So the security is essentially as strong as the Confluence User security?

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.

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

~~~
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?

~~~
haldean
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...](http://security.stackexchange.com/questions/8245/gpg-file-size-with-
multiple-recipients)

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

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

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

~~~
jiggy2011
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.

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

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

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

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

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

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

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

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

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

~~~
superchink
Do you have plans to allow others to use this?

------
raverbashing
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

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

~~~
raverbashing
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

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

------
lflux
Binder in the safe.

