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.
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.
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
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..
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 :-)
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.
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.
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)
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.
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.
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).
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.
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.
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.
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.
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.
66 comments
[ 3.3 ms ] story [ 115 ms ] threadSecrets: In a closed office, verbally.
"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."
[0] http://www-03.ibm.com/software/products/en/pim/
edit: video demo https://www.youtube.com/watch?v=CITq80gf6Hk
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.
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.
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.
But as you say, it's better not to have the secret at all.
Cheap, effective and good security track record.
That being said, we use personal accounts for all external services. All personal passwords are stored in 1Password.
Price is right, though.
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
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.
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.