Co-founder & CTO at Algolia
Sorry, there is no results for this query
It is a very common practice and a very bad idea to send sensitive information over Slack or email. No matter how much you trust Slack or Gmail, there are types of company information (for example, SSH keys, certificates, security tokens…) that warrant an extra layer of security.
The challenge, then, is to create a more secure platform that is also easy to use in order to invite adoption.
Being part of the security team, I send secrets and passwords on a daily basis. Existing ways of sending secure messages were quite cumbersome: you had to first ask the receiver to create a private and a public key, have them publish it somewhere like a web site, MIT’s public key service, or KeyBase, or send it directly to our squad. Only then we could start sending secure messages to each other.
While operations engineers are used to (if not happy with) this level of effort, asking other teams— dev, sales, marketing, execs — to indulge in such a procedure is simply not practical: I could already see employees reverting back to email or Slack.
Experience has shown us that the best way to mandate security measures is to make them as simple and easy to use as possible. Hence, I started racking my brain to find a new solution.
While working on a different project in our continuous efforts to make Algolia security top notch, I started using Hashicorp Vault. Vault “secures, stores, and tightly controls access to tokens, passwords, certificates, API keys, and other secrets in modern computing. Vault handles leasing, key revocation, key rolling, and auditing through a unified API”. Through Vault, Hashicorp changed the way companies store their secrets.
Digging a little deeper inside the Vault API and engine, I stumbled upon the concept of Response Wrapping. “Response Wrapping” is using Vault’s cubbyhole backend. Cubbyhole is a short-term storage place where you can put a secret that will be consumed by a user or a service who is holding a specific token. No token can access another token’s cubbyhole, whether to read, write, list, or for any other operation. When the token expires, its cubbyhole is destroyed.
So, a Vault token has all the features we need to create a self-destructing message service:
Let’s put all of these features into use and create a secret message service workflow:
Now, before building the final tool, I did some research to make sure I am not reinventing the wheel. I decided to look for a self-destruct messaging software, and found a couple of candidates, but they all had at least one of the following issues:
Side note: I don’t explicitly list the tools because the “domain” of secret messaging services is so tiny, that I believe your own research will take only a few minutes to come to the same results as I have. You can see a list of some nice projects here:
The research justified building a new tool with the following requirements:
All I had to do now is create a very simple API with 2 public methods:
On top of that I built a very simple web UI:
And that’s all there is to it!
While this was at first just an experiment in using Hashicorp Vault for a secret messaging tool, it has really caught on at Algolia, where I see many coworkers using it for all kinds of secrets sharing.
If you like the tool, you can try it yourself on GitHub. It is open source, and we put on ProductHunt so it can be found easily (and of course, we’d love your vote 🙂
Let us know what you think!