
Ask HN: How Do You Securely Share Passwords in Teams? - s9ix
How do you securely share passwords and secrets in a startup or organization? We&#x27;re currently using Meldium but looking at other alternatives.
======
MikeKusold
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.

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

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

------
AaronFriel
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](http://imgur.com/a/ekoO2)

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

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

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

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

~~~
simonw
Do you have a company Twitter account?

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

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

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

------
cones688
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/](http://www-03.ibm.com/software/products/en/pim/)

edit: video demo
[https://www.youtube.com/watch?v=CITq80gf6Hk](https://www.youtube.com/watch?v=CITq80gf6Hk)

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

------
damon_c
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](https://www.gnupg.org/gph/en/manual/x110.html)

------
lotsofcows
A couple of KeePass files in DropBox.

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

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

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

------
lowry
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](https://github.com/shadowhand/git-
encrypt)

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

------
furyg3
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/](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.

------
karthikv2k
[https://www.secureshareme.com/](https://www.secureshareme.com/)

Pros: 1\. Open source tool, you can run internally in your company.
[https://github.com/saravanacp/secureshareme](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.

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

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

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

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

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

~~~
coherentpony
In another smb share.

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

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

~~~
bazzargh
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](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.

------
payaaam
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](https://www.virtru.com/other-
platforms)

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

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

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

------
kennu
Keystok ([https://keystok.com/](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.)

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

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

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

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

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

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

~~~
chr7z
+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.

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

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

------
1111y
Keepass wallet stored on a secure, internal network.

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

------
tvon
Team Password [http://www.teampassword.com/](http://www.teampassword.com/)

------
surfacedamage
Hands down: [https://www.meldium.com/](https://www.meldium.com/)

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

------
mbesto
LastPass

Cheap, effective and good security track record.

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

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

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

~~~
icebraining
Clickable, for lazy people like me:
[https://www.passpack.com/](https://www.passpack.com/)

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

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

------
eli
What don't you like about Meldium?

------
josefresco
Google Drive/Docs.

