Secure and simplified config


Secure and simplified config

Envkey is an end-to-end encrypted repository for configuration, api keys, and application secrets.

Instead of spreading copies of potentially sensitive data all over the place in plain text, Envkey lets you store all your config in one secure location, then grant revokable need-to-know access to developers and servers. You can manage everything through a friendly web ui and keep your config automatically in sync wherever it's needed.

Had same idea some time back. I think there's a need for such tool.
How does the end-to-end encryption work. Does the local key I use as a developer serve as my decryption key? If so, is it ever sent to the server? If not, how do you determine which keys are for which account?
@marckohlbrugge Good question - I'm planning to do a writeup on the details soon. The end-to-end encryption design is quite similar to ProtonMail's. They have a good overview here: https://protonmail.com/security-details

All encryption is based on the OpenPGP standard, using both OpenPGP.js and Golang's OpenPGP implementation compiled to native extensions for client SDKs.

For each user and server, the server stores both a public key and password-protected private key. The server never sees the password, so the strength of the encryption from the server's perspective is effectively the strength of the password. For the web client, this is a user-supplied password (with lots of prodding to make it a strong one). For servers and local development keys (used by the SDKs), it's a 14 character random alphanumeric string securely generated on the client.

The usual caveats about web encryption do apply (which is why native apps/extensions are also in the works), but the in meantime, Envkey mitigates these issues with every technique currently available. Envkey's web client loads no 3rd party content and maintains a strict content security policy, drastically reducing the risk of XSS attacks. All assets, including the root document, are served statically by a CDN server, not dynamically, further reducing the surface area for a JS-based attack. On top of this, we are rigorous about back end security, so the end-to-end encryption, while solid, is only the outermost layer of protection. Data at rest is also encrypted with our own keys and only our load balancers are accessible to the public internet.

I hope that helps. Let me know if I can provide more info or clarification on anything!

@Danenania Wow, great job on the reply. Sounds like you know what you're doing :)

Join to leave a comment