Would also like to give a shoutout to Stytch. We've used them since day 0 to build our entire auth system, and have found the overall dev experience to be quite great
The vulnerability issue that you reported, if I recall correctly, was relating to server-forwarding attacks via our API playground. We've addressed that issue around 8 months ago, and unfortunately, it was not the root of this incident.
This is Han, I'm one of the co-founders from Mintlify.
For the security of our customers from the publicity we were expecting from the announcement, we've decided to leave out the technical details of the breach in the blog post.
The source of this security incident was due to an uncaught error response in one of our APIs that didn't properly format the response before sending it back to the client. The response contained our internal admin tokens, which can then be used to access internal endpoints, which unveiled sensitive user information.
Our initial patch upon discovering the incident fixed the response of the vulnerable endpoint, but we have since also implemented a sweeping number of security provisions and are also in the process of completely deprecating the admin tokens and GitHub OAuth entirely to prevent an incident like this from ever happening again.
>"we've decided to leave out the technical details of the breach in the blog post"
>"Our dedication to transparency, security, and the trust you place in us remains unwavering."
You are contradicting yourself here.
>"The source of this security incident was due to an uncaught error response in one of our APIs that didn't properly format the response before sending it back to the client. The response contained our internal admin tokens, which can then be used to access internal endpoints, which unveiled sensitive user information."
Why would you leave that out? Seems like it is vital information.
> For the security of our customers from the publicity we were expecting from the announcement, we've decided to leave out the technical details of the breach in the blog post.
This doesn't exactly inspire confidence that your service is now secure.
It's most likely not. Not sure if this was intentional but they pretty much confirmed it in a reddit thread:
> ... and are also in the process of completely deprecating the admin tokens for a more secure internal authentication procedure. Not to mention, we're also looking to fully deprecate the need of the GitHub OAuth tokens entirely in the coming weeks.
Infrequent posting low karma users showing up on a random thread after nearly a year of inactivity to call out a relatively niche player which gets immediately replied to by the founder looks suspicious, I have to say. (EDIT: The founder has since deleted their comment, it had been quite downvoted before I replied)
We have similarly simple UX but are more robust on security. Browser-based end-to-end encryption as offered by Infisical is a bit of a fig leaf—it doesn’t protect against insider threats.
I wouldn't undermine and characterize it as fig leaf personally. I think this would raise a natural question on my end which is how do you evaluate the security of platforms like 1Password, Bitwarden, Vault, all of which also offer browser-based alternatives?
Well, what’s the point of end-to-end encryption? It’s so that even if the service gets hacked or has an employee go rogue, sensitive data will still be safe, right?
That’s what the average person thinks they are getting when they sign up for a service that advertises end-to-end encryption, but when it’s browser-based, that simply isn’t true. If a browser-based service gets hacked, it’s trivial for an attacker to disable the encryption, steal private keys, or just steal secrets directly, and it can be done in a way that leaves no record and is very difficult for the end-user to detect.
So you have a security measure that is implemented in a way that fully subverts the stated purpose of said security measure. I think fig leaf is a fair characterization.
You’re right that Infisical is far from the only product doing it. Though it’s fairly common knowledge in the security and encryption community, most developers and most users of these products aren’t aware of this issue, so for now, there isn’t a lot of incentive to do it right.
First off, I want to point out that browser-based services and applications can be made secure; we should keep this one clear, especially for readers here, because otherwise it would invalidate most if not all services that exist accessible via browser. Take AWS which houses infrastructure for so many organizations; we access it via browser and this is totally fine.
The assumption you highlight is specifically "if a browser-based service gets hacked." Well yes, if any browser-based service, like AWS, got hacked then it'd be all game over. However, given that appropriate security measures are implemented/taken, we can in fact design web applications that are securely accessible via browser; this is the basis for how we access applications on the web securely, those that are not end-to-end encrypted (E2EE).
What I'm trying to say is that your assumption is based on a particular case that is "if a browser-based service gets hacked." I think, however, if this assumption occurred to many other non-E2EE services we use on a daily basis, we'd have a huge problem as well. Now, the reverse assumption that is the browser-based service is not hacked, coupled with an E2EE architecture, I believe it's possible to design a secure system here where even the server cannot read the values of secrets which is a point of E2EE.
Sure, my point wasn't that a browser-based product is automatically insecure, just that end-to-end encryption implemented in a browser has minimal security benefit. The whole point of E2EE is to avoid leaking data even if you do get hacked or have an employee go rogue despite your best efforts.
"even the server cannot read the values of secrets"
I have to disagree there. Your server can easily read the values of secrets--it just needs to include an extra snippet of JS in the response to a single request. You're asking users to trust that your server won't do this, but they have no practical way to verify it. That isn't the case for EnvKey, which is all I wanted to point out.
Please don't take it the wrong way--you have clearly built a product that has good UX and that people like and I congratulate you on that. Many users out there will probably prefer the tradeoffs you've made, while others will prefer EnvKey's. I think it's fair, in the spirt of friendly competition, to highlight where those differences are so that people can make up their own minds with an accurate understanding of the threat model of each approach.
Totally agreed. While the frontend and core functions are open source, the backend under the `server` folder is source available. We made the mistake of referring to the entire repo as open source, which we will refrain from in the future.
We totally agree! We think it would be best when documentation is centralized, version controlled, and coupled with the code. Unfortunately, we realized that's just not the case for the vast majority of companies. One way to think about our product is just bringing the features of documentation on GitHub into existing documentation that lives outside of it.
> Unfortunately, we realized that's just not the case for the vast majority of companies.
Nor is DevOps, but that's changing. And as more things shift-left and get actioned in a CI/CD pipeline, companies are going to want more automation, checks, analysis, etc., of all their digital assets. That includes documentation - spell checks, auto-generated and static, checking for broken links, warnings about docs that haven't been reviewed or updated for X days, and more.
That's the real answer to this problem: how do we keep documentation close to the context to which it relates, AND allow it to be manipulated, tested, and more, all through automated business logic? Solve that.
> how do we keep documentation close to the context to which it relates, AND allow it to be manipulated, tested, and more, all through automated business logic? Solve that.
That is correct. The backend covers enterprise features that are only source-available, whereas the rest of the application is open source. We understand that this can be quite misleading, and will refrain from saying that we are open source in the future
I also suggest you add documentation to the github repo. The first thing I did after reading the first paragraph of this announcement was checking the source code. And when I saw no documentation at all - zero - nada - niente, I completely lost interest in looking more into the project (I was quite enthusiastic, given your description, so seeing no docs was an incredible turn-off).
Thank you for sharing the article! We definitely don't see companies having all docs in their repos, but strongly believe that there should be stronger ties between docs and code (and more transparency in docs in general)
It's a really hard problem to solve, but we believe that there will be a product that will crack it (even if it's not what we have right now)
Thank you so much for the incredible feedback! We think you are absolutely SPOT ON. We would really love to chat more with you 1:1. Please reach out to us at han@mintlify.com
