Ask HN: How do you manage shared company passwords?
30 comments
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.
Inside engineering, we have been experimenting with a shared keepass db that we move between machines directly using git.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Wouldn't this mean ex-employees would know your password scheme indefinitely?
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.
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 they're random passwords, they'd need ongoing access to the password database. (If there are suitable protections against the database being exported.)
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.
No, each website has a unique username for the admin system, thought these are normally just the company name.
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
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
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.
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.
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?
Actually - I am going to stop guessing - how do you arrange keys and decryption please?
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.
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.
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
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
> 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.
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'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.
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.
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.
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.
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.
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?
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...
[0]: http://security.stackexchange.com/questions/8245/gpg-file-si...
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 [email protected] -r [email protected] plain.txt", and for decryption you do something like "gpg --output plain.txt -d plain.txt.gpg".
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 [email protected] -r [email protected] plain.txt", and for decryption you do something like "gpg --output plain.txt -d plain.txt.gpg".
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.
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.
We use a Google Docs spreadsheet on our internal Google Apps account.
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.
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.
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.
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).
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)
It works in small groups (we're three guys using it, two more frequently)
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?
afaik the second user should open it read only, so it cant update (that's why I was saying that the user should close it after having read/written some data)
That was true for Keepass 1, but since 2 I think everyone can open it read/write? I think I'm prompted to "synchronise" when I save if another user has saved since I first opened it.
Ah, if KeePass v2 allows for synchronization, then that solves the big problem of people overwriting each other.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
As alternatives, kerberized FTP will allow you to generate keytabs and many scp setups have public key auth enabled.
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.
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.
We now use http://www.passpack.com/ to easily share passwords and other credentials with my staff.
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).
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
[1]: https://github.com/github/swordfish
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
Maybe we are trying to solve the wrong problem :D
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.
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.
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.
"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.
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.
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.
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.)
We've been using https://www.boxcryptor.com/ on top of Dropbox for passwords and other need-to-keep-very-secure data.
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.
I'm using cpm[1] with revision control (git).
https://github.com/comotion/cpm/wiki/Revision-control
https://github.com/comotion/cpm/wiki/Revision-control
We built our own for our consultancy: http://www.youtube.com/watch?v=Qicebedl_X4
Do you have plans to allow others to use this?
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
A good solution would also be able to manage private SSH keys as well
For what purposes do users need to share private SSH keys? The trusted keys file can hold an arbitrary number of public keys.
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
we use passpack - it's really easy to use, seems secure and nice
Binder in the safe.
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/