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.
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.
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.
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..
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.
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).
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.
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.
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.
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.
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.
[+] [-] MikeKusold|12 years ago|reply
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|12 years ago|reply
[+] [-] AaronFriel|12 years ago|reply
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
[+] [-] s9ix|12 years ago|reply
[+] [-] tekknolagi|12 years ago|reply
[+] [-] aroch|12 years ago|reply
Secrets: In a closed office, verbally.
[+] [-] bjelkeman-again|12 years ago|reply
[+] [-] cones688|12 years ago|reply
[0] http://www-03.ibm.com/software/products/en/pim/
edit: video demo https://www.youtube.com/watch?v=CITq80gf6Hk
[+] [-] emeidi|12 years ago|reply
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.
[+] [-] emeidi|12 years ago|reply
[+] [-] damon_c|12 years ago|reply
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
[+] [-] lotsofcows|12 years ago|reply
[+] [-] eli|12 years ago|reply
Price is right, though.
[+] [-] peterwwillis|12 years ago|reply
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|12 years ago|reply
[+] [-] lowry|12 years ago|reply
https://github.com/shadowhand/git-encrypt
[+] [-] Corrado|12 years ago|reply
[+] [-] furyg3|12 years ago|reply
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.
[+] [-] karthikv2k|12 years ago|reply
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.
[+] [-] icebraining|12 years ago|reply
[+] [-] jsegura|12 years ago|reply
[+] [-] beerbajay|12 years ago|reply
[+] [-] brokentone|12 years ago|reply
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|12 years ago|reply
But as you say, it's better not to have the secret at all.
[+] [-] payaaam|12 years ago|reply
That being said, we use personal accounts for all external services. All personal passwords are stored in 1Password.
[+] [-] hamburglar|12 years ago|reply
[+] [-] geoffsanders|11 years ago|reply
[+] [-] kennu|12 years ago|reply
(I'm one of the developers. It's a commercial SaaS service.)
[+] [-] kruk|12 years ago|reply
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|12 years ago|reply
[+] [-] jcfrei|12 years ago|reply
[+] [-] matthewcford|12 years ago|reply