Comment by tompic823 | Hacker News Reader

Comment by tompic823 | Hacker News Reader

Parent Full thread

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?

Reply on news.ycombinator.com