Hashicorp Vault is more difficult to put in place but it does the right thing. With it's custom backend it can generate temporary tokens, for example to access the database. Those token are short-lived and part of the audit log.
Only users or machines with explicit access can retrieve the encrypted secrets from our servers and they are never written to disk in plain-text.
With our worklog(1) feature, we make it really easy to rotate secrets when a team member leaves, commits them to git by accident, or a machine is compromised by listing out every secret they could access cryptographically.
For small teams and deployments, we want to make it easy for them to keep their secrets out of git without having to securely manage and deploy heavier tooling such as Vault or Keywhiz.
1) https://www.torus.sh/docs/latest/commands/organizations#work...
They seem to have pretty serious access control (Orgs, Teams) and a Policy based access control system.
Heck, how do people manage their personal credentials and secrets? I have a few computers, and I usually copy over a few PGP keys, SSH keys, and API keys. For regular credentials, I use a password manager which syncs through a cloud data storage system.
One of the best sites I've found for learning about security-related topics is the NIST CSRC [0]. They cover a huge variety of topics, with varying levels of detail. I've found many of their publications to be very approachable. For example, they usually include a glossary of terms and acronyms, along with examples to help you understand the problem. Also, unlike what you find in many popular books or random online blogs, they actually cover varying edge-cases and discuss an example of what a real-world solution could do. I love that because it gives you a reasonable starting point for when you don't know any better. The only problem is that their content generally isn't written with personal usage or small teams in mind.
Reading the docs, though, it does seem like it's one legendary AWS outage away from being a huge problem:
>Torus’s infrastructure has been designed from the ground up for resilience without any single point of failure. All of our services are autoscaled and run in multiple availability zones in the us-east-1 region.
Maybe it's not a good idea to launch in the default region.
It looks like there are plans to open-source the server, though, so that problem can be solved if you want to host your own Torus deployment (which I'd likely do for any serious non-personal usage).
I personally found the experience of using Torus to be great. Getting a quick working setup is easy and it doesn't take much effort to transition from there to locked down access control. Will likely continue using it outside of the Docker context.
To do this, we designed our security model (host and cryptography architecture) for hosting in the cloud to ensure we never have access to any of the keys used to encrypt or sign secrets — they’re derived from a user’s password and never forwarded along. We’ve posted more information in our documentation(2).
The server is currently closed source, with plans to open source it. The client (where all cryptographic operations happen) is open source.
1) https://www.manifold.co/ 2) https://www.torus.sh/docs/latest/internals/crypto
Doesn't solve the lack of mobile support, but hopefully the fact that the client-side code is already free software (and under a liberal license, to boot) means that the community can fix that problem if all else fails.
