What technologies, protocols, and processes do you use to pass around private keys? I find some of the more secure practices involve extra steps ...
For further actions, you may consider blocking this person and/or reporting abuse
At Manifold, we built Torus CLI for sharing secrets between humans and machines from development to production.
It integrates directly into your workflow, so you can model the way you store your secrets to the way you organize and deploy your code. All of the secrets are encrypted on the client using an elliptical curve keypair derived from the users stretched password.
Today, we're using it across our different code bases, from sharing secrets in development (for testing email, or other cloud services) to integrating directly into our CI/CD flow for our Single Page Applications to ensure none of our deployment or build secrets ever touch disk.
To give someone access to deploy our core stack using terraform, we just add them to the
devopsteam and then they can runtorus run -e production -- terraform apply. No decrypting files using gpg, dealing with binary merge conflicts, or educating users about keeping secret keys safe.When it comes time to rotate a secret, with one command it's out of rotation, we just need to deploy to bring everything up to date. Most importantly though, when someone leaves our company or changes teams, it's really easy for us to track down which secrets need to be rotated using the
torus worklogcommand.It's really reduced all of the day to day friction to working with secrets, from giving people access, to ensuring they're up to date.
We're a small team in a university setting, 7 members, of which 3 are not really involved in our system/need quick access.
We now use pass (passwordstore.org) and Git on a in-house repository. This of course requires that all members that need access to secrets maintain a properly secured GPG Key. Strict hierarchy and access on a as-needed basis for every person. Integrates beautifully with Ansible, which we use for CM and Deployment.
Before that we used a mixture of Keepass and Ansible Vault, which had the restriction of one global password that everyone knew, so we needed to split this file up into two for two separate "security levels", which was really cumbersome. Syncing was really annoying. Transfering from Keepass to Ansible Vault was a pain, so we started keeping passwords only in vault. Accessing a secret? Open your personal Keepass to get the Password for the Group Keepass, Extract the Vault Password, Open the Vault, read the secret.
I remember a time where I wrote a password on a sticky note. Showed it to someone who would then type it in, walk outside and burn the sticky note.
Luckily times have changed!
I now use a variety of tools depending on the situation.
Private keys or passwords we share on Keybase when the number of people that are allowed to know is limited. Or when we just need to pass it securely.
For organization-wide accounts we use LastPass.
Personally I like 1Password better, so I use that for my secrets and passwords.
I've seen some other mentions below, including crypto.cat, so I will check that out as well. Thanks for sharing!
We used to allow password manager of choice, KeePass being popular. But then they locked it down, and you're only allowed to keep them on an application called Secret Server that has a bunch of features like temporary privilege escalation.
Keybase has made this easy and rather painless, though I still think they have some work to do (e.g. why should we trust them?).
Other than that, home-grown tools that create secure secret lockers in github work OK, so long as you wrap the difficult PGP bits. At Rackspace, we had a template project for these kinds of things. (See github.com/racker/secure-template).
If you just need to pass one-off chunks of data encrypted end-to-end, I've used KeyVault a lot. You paste the thing into the form, copy the link it gives you, paste it into a chat with your recipient, and they open it in their browser, save the thing, then click the "Destroy" link. No registration, just ephemeral blobs of encrypted data.
The other thing I've used in the past for longer-term stuff is HashiCorp Vault. It's awesome, but requires you to host it yourself. You can store the secrets on the server's local hard drive or S3 or one of almost a dozen or so other places. Everything's encrypted at rest and it can be used to store secrets for your company's apps (DB logins, tokens/keys for 3rd-party services, etc).
A lot of our passwords are just the name of the company plus a few numbers.
(Don't worry, really sensitive things use ssh public key authentication. Since all keys involved are public it's fine to put them in Slack.)
We host our own One-Time Secret instance. Our security policy calls for employees to use password managers to store their own passwords & generally prohibits shared logins. If there's a shared key or password that needs to be documented, we insist it's stored in our project management system where it's behind a login and we can control who has access to it.
If you don't want people bypassing policies for expediency, it needs to be addressed culturally. Make it clear that they won't be hassled for taking time to share data securely and protect your people from that pressure. Explain why your rules and chosen tools are in place. Nobody wants to be responsible for the next big credit card or medical data leak, right? So make it clear that they're on the front lines of protecting your clients & customers from identity theft. They have the power, tools, and management's support to do their job responsibly. They won't be the faces behind the nasty headlines.
One of my previous companies used Cryptocat exclusively for this. :)
So typically people would interact on a different platform, like Slack, etc. and then dip into Cryptocat to share secrets?
Yes!
We whisper them from trusted person to trusted person. Digit by digit...
My favourite reply! :D
Currently in our team, we are studying using gopass, given that it is backward compatible with pass, but supports multiple PGP recipients and multiple mounts, which would allow, for example, a personal mount and a per-project mount to share secrets using one git repository per context.
Of course, the main issue there, as they tell themselves to theirs users is that, given that it works with a git repository, if a PGP recipient is excluded from a set of secrets, there is a need to remember to change each service password, given that the removed recipient could have a full copy of the commits which would allow to access old secrets by using old commits, even if in the most recent commit excluded such PGP recipient - just check this link's git history and local files section. So in such scenario, the system admin must remember to change each and every shared secret in that repository and in the services themselves. Of course, it should be a standard security policy in any team, but who did ever forget to change a vital secret in such situation?
This comment is based in sharing secrets more permanently. If I misunderstood your proposition, please correct me.
I've been looking at using passbolt for out company but it currently only supports passwords and not other credentials such as API keys and SSH keys
Someone shared this on Twitter: keedrop.de. I really love the brutal simplicity. This is a great tool to fight the lazy one-time-until-it-isn't-actually-one-time Slack message.
Nice one ! :)
LastPass secure notes
We use our password manager of choice, with separate vaults to ensure nobody gets lost in the noise.