Hacker News Reader

Comment by gingerlime | Hacker News Reader

Congrats on the launch. Great to see more products in this space.

I'm also familiar (but never used) Envkey, which I think might also be from the YC alumni? but I'm not sure...

Shameless plug: I created an open-source tool called envwarden[0], which is really just a simple wrapper around the Bitwarden[1] CLI (also open-source). envwarden helps you manage your server secrets and other variables inside your Bitwarden password manager.

Definitely not as polished as neither Doppler nor Envkey, but just another (open) alternative I guess :)

[0] https://github.com/envwarden/envwarden

[1] https://bitwarden.com/

View on HN

Super happy user of EnvKey here - I'd be interested to hear what sets Doppler apart.

We are friends with the folks at EnvKey! Our core philosophy is what’s different, we focus on building something for the everyday developer, where we abstract as much overhead as possible. A example of this is how you log into the Doppler CLI when developing. The “doppler login” command takes you to the browser and you sign in like how you would any other site. There is no need to remember API keys, everything is handled behind the scenes for you. Other things that set us apart: audit logs, versioning, and rich integrations with production infras like AWS, GCP, Heroku, Vercel, Netlify, etc.. Besides that, our pricing is much more friendly, we offer a free tier for unlimited users for all the core functionality.

Founder of EnvKey here. I'm glad to hear you're a happy user :)

There's certainly room for alternatives in this space! I'd say the major difference from my perspective is that EnvKey uses client-side end-to-end encryption and a signed desktop application instead of a web app interface, giving it quite a different security and trust model than Doppler.

Because Doppler is delivered as a web app, its users are implicitly trusting Doppler's servers on every request. If their servers were compromised, user data would be at risk despite any tokenization or encryption they might be using on the back end, because the attacker could simply inject malicious javascript into the html of the initial web app request. EnvKey's architecture doesn't allow this.

Hey Dane- totally fair points. Agreed that Doppler and EnvKey have different threat models. Regarding your point about malicious JavaScript- I'd encourage you to take a look at our Content Security Policy. We've gone to great lengths to explicitly disallow all unsafe-inline JavaScript (technically in report mode, but will be moved to block mode within the next few days). This is just one of many things we do to help keep our users secure, but I figured it was worth addressing directly. We've also undergone extensive internal and external audits and pentests to ensure we're not susceptible to XSS and CSRF (and employ development practices to prevent us from introducing these vulns).

I'd also argue that EnvKey might be a bit too absolutist about security, in that we think the user experience greatly suffers as a result. We have a different tradeoff that emphasizes secure defaults and best practices while also allowing for necessary features like audit logs and syncing with different infra providers. We spent quite a bit of time considering the tradeoffs of zero-trust, but our user experience would suffer as a result, and so we have taken a different approach.

Hey there! I completely agree with you on the tradeoffs between UX and security when it comes to end-to-end encryption. It's a tricky balance to get right, and I think it's great that there are multiple approaches out there in the market. People should weigh their own unique needs and comfort level when making the choice.

That said, a Content Security Policy doesn't actually address the issue I'm raising, because an attacker with server access could simply remove or modify it.

Server access is an interesting scenario to explore. If we're considering an attacker gaining server access, what's to stop that attacker from shipping a modified EnvKey binary that steals your customers' secrets and their encryption keys? If the security of your binary is predicated on GitHub repo access, what happens in the event of GitHub account takeover? At some point, no system is infallible, and I think our Threat Mode adequately addresses this. I appreciate your point of view on this though.

The private certificates that sign our binaries are tightly controlled and not accessible to our servers or our GitHub accounts, so the scenario you're describing could only happen if an attacker compromised our Github account and our private signing certs (gaining access to our back end servers wouldn't help an attacker at all).

Of course, no system is invulnerable to any attack. But in practice, Doppler's architecture implies a much larger degree of trust (any server breach = secrets compromised) than EnvKey's (servers can be fully breached and secrets still aren't compromised). Doppler looks like a great product in many other ways, but I do think it's important for users to fully understand the risks they're taking.

Although the approaches are different, they both address a security need for all developers. For EnvKey it would be nice if you address the freelancer/single user Marketing tin some way - $20 a month for 5 users is a bit pricey for 1 user. Is that something you are considering?

EnvKey user here - it looks exactly like EnvKey. Not sure what the underlying crypto primitives are - EnvKey relies on PGP/GPG style stuff and have a lot of documentation about it.

Oh, I just recently started using envwarden for managing dev secrets. I have some customizations for that use case on a fork, in case it's helpful to anyone: https://github.com/envwarden/envwarden/compare/master...simo...

That is awesome, I love seeing contributions in this space!

Reply on news.ycombinator.com