Ask HN: How Do You Securely Share Passwords in Teams? | Hacker News Reader

Ask HN: How Do You Securely Share Passwords in Teams?

48 pointss9ix64 comments

How do you securely share passwords and secrets in a startup or organization? We're currently using Meldium but looking at other alternatives.

View on HN

Ideally, you don't share passwords. If it is a server, every user should have their own account with sudo access if needed.

If it is a website that you are unable to add multiple users to an organization with, LastPass has a password sharing feature that doesn't directly expose the password with people you share it with. Although if someone cares enough, they will be able to find it.

Any time an employee leaves a company, all shared passwords should be reset. It doesn't matter if it was an amicable departure or not.

This is pretty much how we do it. We have many sites that only allow a single user and we use LastPass for sharing passwords with the relevant groups of users that the site accessed by.

We also use LastPass. It has the knock-on benefit of getting everyone used to LastPass, and they inevitably start using it to manage all their passwords, and generate secure ones for all sorts of different sites where they would otherwise use the same password across sites.

I'm working on a piece of software (SaaS, self-hosted) that acts as a reverse proxy and stores credentials. The goal is to avoid having to require users to know any secrets other than the ones you already trust them to have (a domain login, a Google Apps account, etc.) The goal is to have a single-sign on for the entire internet, and any topology of mapping users to accounts. Account per user could be used if you want to provide access to individual (but company controlled) Reddit, email, Trello, etc. accounts. Many users per account could be used to manage Facebook, Twitter, et al. And access policies can control whether or not users are allowed to send particular types of requests or visit URL fragments.

It's a work in progress, I have an online parser/rewriter for HTML, CSS, JavaScript that can handle moderately complex websites now, including Facebook. Might have something ready by the end of the summer.

Here's an album with some screenshots from last year: http://imgur.com/a/ekoO2

This looks neat - thanks for the share. Feel free to message me progress :)

Looks awesome! I'd love to get updates.

Passwords: We don't. Everything that could use a password is either keyed or certificate auth. Edit: I should add that there are things that use passwords but those are user-specific accounts or communal accounts (which are considered, essentially, public accounts) and are accessible only on the internal network. Users are responsible for the safe-keeping of those passwords and user accounts can do no harm, so to speak, if compromised.

Secrets: In a closed office, verbally.

Don't you have external services which use a password? DNS provider, VPS admin console for example?

Not really, we have our own datacenter and DNS servers. We have HSMs for somethings (like CA certs) and yubikey/similar for things that require passwords but those are all protected by user-specific certificates.

Do you have a company Twitter account?

Yes/no, one exists but its unrelated to my job. Its probably worth noting that we also have sets of accounts that while password protected are essentially considered public. Those accounts are accessible to anyone who knows the well-known standard passphrase

It kind of negates your first point.

"Passwords? No. We don't. Everything is a certificate or key."

...

"We have sets of accounts ... accessible to anyone who knows the well-known standard passphrase."

As a company "we" don't have passwords for our company infrastructure, individual users may have passwords for their accounts but those aren't secret/ as important. Its not practical to deploy PKI to and expect ~100K users to use it. As for communal accounts they're almost all for paying for services offered in-house by a group other than yours.

Large enterprises usually use PIMs (Privileged Identity Managers), web based consoles where you check out credentials for the task. I have seen IBMs and it has some pretty creepy (if you are the dev)/powerful (if you are CISO) features like session recording etc [0], does allow you to see who used what at what time and rotates passwords for the systems required between use..

[0] http://www-03.ibm.com/software/products/en/pim/

edit: video demo https://www.youtube.com/watch?v=CITq80gf6Hk

As an IT Auditor, I have seen one such tool at a client once and found it to be the best solution for this specific problem (if personal logins and sudo or another custom made script couldn't do the trick).

But I've also come across dozens of unprotected .xlsx and .txt files stored on group shares which give me shivers every time I see it.

"rotates passwords" Which I think is an awesome feature, especially when the rotation can be forced. Also, very desireable, one-time passwords. And a way to enforce password complexity and to prevent the same password being used for two different devices. And a way to audit password strength and rotation, of course :-)

I've been thinking about this lately and it occurred to me that it would be nice to be able to store sensitive info in an area accessible to everyone on the project but still be able to limit access.

Currently we use ssh keys to limit access to servers and code repositories so the perfect solution would allow passwords and such to be protected by similar means.

I believe gpg[0] has a solution but I have not implemented it myself yet.

0: https://www.gnupg.org/gph/en/manual/x110.html

A couple of KeePass files in DropBox.

Same here, but I don't love it as a solution. Kinda cumbersome, especially if you've got different groups of users who need access to different (overlapping) services. And then of course you have to communicate (and hopefully occasionally rotate) the master password(s).

Price is right, though.

Write it on a post-it, walk up to the person, give it to them, then take the post-it back.

Passwords are designed to be human-interface memorized authentication tokens. Sharing it any other way than via human interaction just makes it a digital key, and real digital keys are much more secure than digital passwords. So share it via human medium, or rethink why you're using a password.

In our case, there's not much to think: we're using passwords because that's the only way to authenticate to those services.

None mentioned gitcrypt yet. I used it for 3 years, sharing password in a team of 4. A bit cumbersome to setup, but once you've been through the installation instructions, it just works.

https://github.com/shadowhand/git-encrypt

Thank you for recommending Gitcrypt! I have been trying to remember the name because we have a couple of Git repos that need protecting. We need to encrypt them but I don't want it to be a big hassle to the developers that need to work with them.

For user specific passwords, our team uses whichever software they prefer (usually LastPass or KeePass)

For passwords that can absolutely not be made user-specific, we use SimpleSafe (https://www.simplesafe.net/). It allows you to make groups of passwords and assign rights to those passwords, and has decent logging. It's web based and works ok on mobile.

These few passwords are for network devices, passwords for websites where only one account can be made, or master/root/administrator passwords that we don't use but need to write down somewhere just in case.

These are the keys to the kingdom, so it should be behind VPN/SSH, ideally completely isolated from your regular infrastructure, and with tested backup procedures.

https://www.secureshareme.com/

Pros: 1. Open source tool, you can run internally in your company. https://github.com/saravanacp/secureshareme 2. Very secure: it encrypts the data in the browser and the key is stored in the URL anchortag which is not sent to server at any point of time. Only the sender and the receiver has access to the keys. 3. You can also opt to send a secondary verification code to receiver's mobile for two layers of security. 4. Option to self distruct message based on time or if an attack is detected.

They should point out that it's vulnerable to JavaScript injection, particularly if you use their servers. One simple change and suddenly they can get your key on your next access.

Yes, you are right we can modify our JS and get your keys. This vulnerability is in most of the commercial tools out there too. Thats why it is open sourced so you can run it in your own servers. Running it on your own heroku account is close to zero dollars.

Not sure if giving Heroku that access is any better :)

Password safe in a smb share. I don't really like the idea but it's imposed.

How do you securely share the password to the password safe containing the passwords?

In another smb share.

...that sits on the back of a giant turtle.

Honestly the original "share" isn't the big issue -- many ways to communicate securely. But the history is what will get you if your communication platform ever gets broken into.

Most of the external accounts (log analysis, analytics, CDN, etc) have individual accounts, no sharing necessary, up to the individual to maintain complexity and remember the password.

For other services, certificates and multiple authentication methods (2FA) works out nicely.

OTR messaging gives perfect forward secrecy. So you can't attack the history without breaking AES entirely: http://en.wikipedia.org/wiki/Perfect_forward_secrecy The bigger attack on OTR is social engineering, you need to verify signatures out of band.

But as you say, it's better not to have the secret at all.

When we HAVE to share passwords, we email them using Virtru (encrypted emails). All of the encryption is done client side. You can set the email to expire after 1 hour. No one would ever be able to read it again. https://www.virtru.com/other-platforms

That being said, we use personal accounts for all external services. All personal passwords are stored in 1Password.

A handful of text files containing sets of passwords of similar "privilege level" (e.g. one containing social media logins, one for PayPal or services that cost money, etc), stored gpg-encrypted to specific lists of people and kept under revision control. It is cumbersome, particularly with regard to editing and key management. But it works and doesn't rely on any 3rd parties.

We use KeypassX (https://www.keepassx.org/) and store the encrypted password database inside BTSync (http://www.bittorrent.com/sync), hosted on a secure internal server within our office. Both KeypassX and BTSync are free.

Keystok (https://keystok.com/), which uses JavaScript to encrypt/decrypt secrets in the browser, and also provides a REST API and client libraries to access the secrets programmatically, for deploying API keys to apps etc.

(I'm one of the developers. It's a commercial SaaS service.)

For most of the services we create separate accounts. Nowadays most sites support multiple accounts, those who don't are rare enough to just share a password via email.

Personally I use 1Password for storing passwords and it allows sharing vaults between users so as my team grows we might actually consider using these.

Other than the default answer of "rarely," we've started using a shared 1Password vault. We actually end up using the notes functionality more than anything, but there are some common team accounts in there. Since most of us used 1Password already, it was easy peasey.

If there's no other way than using a shared password, you might resort to using the gnupg suite to encrypt it (and then share it with your favourite messenger/mail client). The necessary programs are usually pre-installed on your distribution.

We've just started using https://www.mitro.co which seems better suited for us, we've created an org, and have teams for different projects/level of access.

We use https://commonkey.com/, it works pretty great and all the encryption is done client side (although the usual caveats about javascript encryption still hold)

+1 for commonkey and their client-side encryption/decryption

+1 for client-side encryption in general^^. Commonkey and Keystok.com both work well, CK just has a nicer UI and Keystok a better API.

I read that as com monkey. :D

so did I!

I might have missed it, but has HN done any kind of review of zerobin? http://sebsauvage.net/wiki/doku.php?id=php:zerobin

KeePass with triggers for synchronization, it syncs on opening and closing the db. Two factor authentication for the db files and separate db file for every unique group.

Keepass wallet stored on a secure, internal network.

"Sharing Passwords" could mean sharing the master account of a service you don't have ssh/certificate access to

Team Password http://www.teampassword.com/

Hands down: https://www.meldium.com/

... this doesn't work for software hosted on premise, right? Especially not enterprise-grade software ...

LastPass

Cheap, effective and good security track record.

Lastpass. It's awesome and easy to use. Wish the UI was a little better but it's not terrible.

Sendinc.com is an option for secure self destructing emails. As much as you trust a 3rd party.

passpack.com -- have been using it for a few years now and never looked back.

Clickable, for lazy people like me: https://www.passpack.com/

+1 for passpack

Why are you looking for alternatives? Looking at this issue myself.

Excel spreadsheet on the network drive. I wish I was joking.

What don't you like about Meldium?

Google Drive/Docs.

Reply on news.ycombinator.com