Launch HN: Infisical (YC W23) – Open-source secrets manager for developers
Our Github is at https://github.com/infisical/infisical.
We previously worked at AWS, Figma, and another startup, where we frequently ran into problems dealing with secret management. For example, many companies used .env files to maintain their development secrets and struggled to keep secrets in sync amongst their teams (this routinely posed security and efficiency issues — secrets can get leaked or go missing). Some companies (especially bigger ones) used solutions like Vault which can be difficult to set up, maintain, and afford.
While secret managers exist, they’re imperfect for many reasons: open-source solutions are either too complicated, not comprehensive, not user-friendly, or a mix of all three; there are nicer closed-source solutions but with no self-hosted options available. The gap we see is to make something that’s simple, open-source, and powerful.
On the open-source front, our goal is to provide full transparency of our codebase and enable anyone in the community to build anything they want in an optimal secret management solution. If you need any feature or integration that we don’t yet support, you can post an issue about it or directly send in a PR to be reviewed immediately.
You can inject the right set of secrets for any environment into your application by using the Infisical CLI together with your application start command (e.g. infisical run -- npm run dev). This removes the need to use a .env file. Everything stays encrypted with encryption/decryption operations occurring on the client-side — under the hood, secrets are encrypted by vault keys for which there are multiple copies of vault keys encrypted under the public key of each member of a vault (ensuring only members of vaults can decrypt secrets pertaining to that vault locally). An alternative way is to use our Open API - though it’s a little complicated, and we’re working on adding SDKs to abstract away the cryptography.
Infisical integrates with staging and production cloud services like AWS, Vercel, GitHub Actions, and Circle CI. We also added support for integrations with Docker, Kubernetes, and Terraform. Infisical is now a central source of truth for secrets across the entire development cycle from development to production with new integration releases every week. One interesting thing is that, by default, our platform is end-to-end encrypted but users can opt out of that if they need to integrate with cloud platforms that require secrets to be sent in decrypted format (e.g. GitHub Actions, Vercel, Render). We’re the only solution that we know of that offers this E2EE-with opt-out ability.
Since our last Show HN (https://news.ycombinator.com/item?id=34510516), we’ve layered authentication with 2FA (more MFA options coming soon) and upgraded all private key encryption/decryption steps to involve a 256-bit protected key decrypted by another key generated via Argon2id KDF from the user’s password. We are starting the process of obtaining SOC2 and other security and compliance certifications. You can read more about our security here: https://infisical.com/docs/security/overview
Beyond this, we’ve added integrations with PM2, AWS Secrets Manager, AWS Parameter Store, Circle CI, Travis CI, GitLab CI/CD, Terraform and more. We’ve also redesigned the main dashboard and added more adv...
123 comments
[ 3.7 ms ] story [ 186 ms ] thread- Infisical is by default end-to-end encrypted which means that we are not able to read you secrets (unless you give us explicit permissions for integrations that require it). This is not the case for many other products in the market, like Doppler.
- "Open source" is actually a big differentiator in this case, because people and companies can self-host Infisical on their own infrastructure. I can't really imagine JP Morgan storing their secrets on someone else's cloud. Many companies we talk to have very strict compliance restrictions, and this is where Infisical come in
I really wish companies would stop using open source as a growth hack.
Technical details: In Infisical, secrets are stored in vaults (we call them projects). They are encrypted symmetrically by vault keys for which there are multiple copies of vault keys encrypted under the public key of each vault member (your teammates). Vault members decrypt their copy of the vault key locally and use that to decrypt secrets (in browser or via CLI similar to platforms like 1Password and Bitwarden); this client-side decryption process makes it impossible for the platform itself to decrypt the secrets itself.
What is meant by users having the ability to give permission to Infisical to access/read secrets is to share a copy of the vault key by encrypting it under one of the public keys of Infisical — we employ an abstract concept of "bots" that have public-private key pairs assigned to each vault. When you share a copy of the vault key with Infisical (which can't happen without your explicit action), it grants Infisical the ability to access your secrets for integrations like Vercel, Render, GitHub, etc.
The permissions switch can only be on the client because that's where sharing the vault key with Infisical by encrypting it under one of its public keys occurs.
Infisical is already pretty easy to self-host but we want it to be even easier — Likely by introducing a 1-click deploy to Heroku/Digital Ocean for folks that need that.
And yea ack with the enterprise space solutions you mentioned. We've a long way to go as a secret manager but I have hopes that one day we'll get to a world-class product that's as good and better!
Basic good practices like this being ignored does not give confidence in other aspects of the business and is a deal breaker for anything related to sensitive data like secrets.
In terms of stability/security, I'm happy to say that we made HUGE improvements to platform-wide security, primarily revamping cryptography dealing with managing private key encryption/decryption operations (adding a protected key mechanism and Argon2id KDF - happy to elaborate more if needed) and adding MFA. Now that we're done with these updates, we'll be adding robust testing going into March and discussing it along with our community.
The CLI "wrap command" is the main way of using Infisical at the moment and works for injecting secrets for local development as well as embedding into your Docker images if you use that; it definitely has pros and cons (a pro is not having to bundle any packages into your application code - in that sense, "dependency-less") but I can see it not being for everyone.
As mentioned we have an open API that we're working to make easier to use because E2EE ops for encrypting/decrypting secrets are not pleasant honestly to have to piece together yourself — because of this we have plans to release SDKs to abstract-away the cryptography (reading/writing secrets from/to Infisical would be one function call away).
What options would you want for interacting with a secret manager, just wondering?
A few tips.
1. It looks like I'm able to do account enumeration on your login page. For a secure app you want to make sure this is not possible.
2. Your CSP https://csp-evaluator.withgoogle.com/ has unsafe-eval. I would lock that down.
3. Your app seems to be JS based, which is OK but it means you have a whole bunch of supply chain attacks on nodejs to worry about. You should only run the bare minimum JS on the frontend when dealing with encryption keys.
4. You're storing keys in local storage. There's a trick you can do, if you store an actual CrypoKey object instead of a string and set non extractable to true you can stop JS extracting private keys.
5. For key stretching looks like your using Argon2-browser. Actually browsers come with a built in with PBKDF2 that runs faster than a JS based argon. So I'm able to get 10 million iterations in a few seconds which is an NIST recommendation.
6. Some of your dependencies look like they are not maintained anymore. i.e. argon2-browser.
This is what I was able to find so far. Hope this helps.
We appreciate feedback we can get across all aspects including security but employ a security policy of reporting any security concerns via email - this is pretty standard practice we've seen.
You don't have a security.txt, https://infisical.com/docs/security/overview doesn't mention it and it's not on your FAQ, so I don't blame ianpurton for not finding it. You have a 'Report a vulnerability' issue template on GitHub (https://github.com/Infisical/infisical/security/advisories/n...) but then your readme points to a security policy which says to email: https://github.com/Infisical/infisical/security/policy
There's also an issue template for reporting vulnerabilities as well as you mentioned.
That said, we'll add info to the security page in our docs to contact us regarding vulnerabilities.
Thanks!
We're fortifying the codebase every day and would expect this process to be complete in the next 2 quarters.
6 months? I'm not being sarcastic here - I'm not on the security or enterprise side of things, but this seems like a long way off for something like a secrets manager. Just out of curiosity, what would hold you back from doing this _prior_ to launching?
As an open source company, we’ve basically “launched” since the moment we open sourced the codebase - it’s a constant iteration process for us and every week we release security updates as part of our roadmap. Security certifications and audits are something we’re starting to do in parallel at the moment whilst still being early in our journey (open sourced 3 months ago roughly).
I feel like somehow your response is the opposite of an ad for your project.
3. Definitely — We're working to cut our dependencies in the coming months. Most existing dependencies (the backend at least - I focus more on this area) we stick to those widely used and those essential to the platform; there're also certain dependencies directly linked to integrations with third-party platforms (e.g. AWS, Octokit - GitHub, etc.).
4. We'll definitely take a look at this — This is on our immediate roadmap as well. We had a few ideas in mind related to a mix of components in browser-memory, session-storage, etc. as well but wanted to make sure we get it 100% right before deploying any changes - based on recommended practices like from Auth0. This article may be relevant: https://auth0.com/docs/secure/security-guidance/data-securit...
5. We actually did evaluate both PKDF2 and Argon2id options in addition to seeing what other secure platforms are doing. We found most to start out with PKDF2 but overtime to introduce support for Argon2id — Take Bitwarden and Dashlane as two examples of this; Bitwarden of which introduced it as of only a few months back. This article may help: https://soatok.blog/2022/12/29/what-we-do-in-the-etc-shadow-...
The choice of Argon2id KDF is sound and recommended; we have it with memory cost of 64MiB, ops cost of 3, and parallelism of 1.
6. argon2-browser is still used well and reliably throughout the ecosystem — take Bitwarden as the biggest example of a solution recently making the switch to use it.
Anyways, happy to move this discussion to email!
I wonder how this compares to Snyk, also in the area of securing against supply chain attacks.
The javascript for the sign-up form doesn't activate the password-strength meter unless ther are keypresses in the primary (not verify) password box. This means when using Firefox auto-suggest strong password, we have to go type and then remove characters from the box to proceed.
Basically, all the features that are needed by individuals and small teams will always stay completely free.
Some of the features that we are thinking to make proprietary are audit logs, sso, role-based access controls. Would love to hear your thoughts on this, because this is still in the very active stage of development!
For example, I would love SSO for my homeserver, so that I can share secrets with my family. I would guess that my family is a "small team", but many open core products don't open source SSO features. Many small actual businesses would prefer SSO too, as juggling multiple logins is as much a pain for a small team member as it is for a member of a big team.
I appreciate any open source contribution even if it is missing features. I understand it can be difficult to sell a product that is 100% open source.
Even when I am implementing something for a larger organization, I always prefer to specify open source over open core.
I end up very rarely adopting any open core product due to missing features- and when I do, I am often spending money re-implementing the closed source features, and thus the money isn't there to pay the company for support. I don't know how common this approach is, I just know a lot of open core products get skipped by me because of limitations.
I agree that it's very hard but that's also why we talk to our community and wee what they say about what features they need. I really happy hope that we can create a great open product for small teams and individuals over a long term too.
Ultimately, small teams often have the same challenges large teams have. I wish you great luck!
PS
At some point you might want to do product comparisons on you site- one of you competitors, Hashicorp does a pretty good job of outlining the similarities and differences as they see it with similiar options, I would suggest following their example. Even if Hashicorp ultimately adds a comparison with your product, having your own perspective is very helpful in making a quick comparison.
In terms of Infisical, this is honestly something we're still figuring out as we're mapping out our roadmap ahead — We try to get feedback from our community in thinking about this since we all contribute to the codebase (also do feel free to suggest what you think would be appropriate).
And yea thanks for the suggestion regarding product comparisons with competitors. We have that on the TODO list in addition to other tasks all related to enriching product information like providing more granular product pricing breakdowns!
They do sometimes give the peasants access to the features months or years later, but the majority of features are still locked away.
After they got that big funding when going public company, free features have been stripped and prices have increased. Same story as usual.
Click to start video only works at the edges of the video, not the center (Firefox 110.0, MacOS)
Happy to help if you have any questions! It's a combination of Next.js + Tailwind + Figma. Oh, and we also use Framer Motion for animations on the landing page.
I also get a lot of inspiration on Dribbble.com
Man I really hate how the term "Open Source" is used nowadays.
ee is only reserved for some features that are (mostly) needed by enterprises (e.g., audit logs, sso, advanced access controls). This helps us get the financial means to also maintain the free ope-source product better.
Re SSO: Totally get this one and I'm aware of the SSO tax — we're still figuring this one out but know currently that it's an absolute must for enterprises.
We recently built an entire product to make it insanely easy to offer enterprise-grade audit logs to your customers. Plus it includes strongly-typed event payload schemas and log streaming to 3rd-party SIEM vendors. Super fast to integrated with pay-as-you-go pricing based on volume. Vercel and others are using this.
https://workos.com/audit-logs
I think we have a shared Slack channel set up with Infisical so feel free to DM me there. You can also email me direct: mg@workos.com. (Same goes for anyone else on HN needing this stuff. :))
Generally, the reason all these companies go and charge for SSO and audit logging is because open core is a land and expand strategy. They offer a free tool that's useful for individual developers, and then when they start demanding enterprise features that means they are integrated into the enterprise and have the opportunity to extract value.
We built out all our OAuth2 integrations with other platforms (different from SSO but something relatable), so we have an idea of how much work it is to maintain these types of “integrations” and related services… Clearly enough to warrant entire solutions like WorkOS dedicated for this exact purpose.
This upsets people, but the larger companies that pay the SSO premium are subsidizing the smaller companies who don't care. I'd rather not pay an SSO tax either, but I'm even less excited about using tools from companies that are going to vanish because they're not generating revenue.
* Especially GitHub. Very opinionated in favor of monorepos.
https://www.gnu.org/philosophy/open-source-misses-the-point....
There's a lot of issues with secret sprawl but I think the relevant one to your specific question mentioning other cloud providers would be having missing secrets across infrastructure (you introduce a new secret to the codebase and forget to update it everywhere else, as well as communicate it or sync it through to other developers on your team) — applications crash, you lose time.
A big idea in secret management amongst others is the idea of *centralizing* your secret management in one place — update here, update everywhere. We help achieve that across your entire infrastructure and have a handy dandy CLI that also helps you inject secrets back into your programs (achieving secret management for local development with zero application dependencies) if you need that :D
I may be misinterpreting your question actually — Unless you mean why use Infisical versus other alternatives on cloud providers like AWS Secret Manager / Parameter Store, Azure Key Vault, etc?
You need to show that you are extremely competent at security -- more so than anyone I can hire myself. You also need to show that you care deeply about security.
For example, the fact that you lock SSO behind a paywall says that you don't care about security. Yes, SSO tends to be an enterprise ask, but it's also important for two person companies. I'd suggest changing at least that part to be 10+ SSO users or something like that, and make the first few free.
Also, your response to security reports in this thread is not what I'd want from a security company. Sure, the right way to report these things is via email, but you should still be grateful for the free security audit you got and approach that with a bit more tact.
At least make it look like you care more about security than revenue and adherence to policy.
Good luck, it looks like an interesting product, just make sure you don't turn users off with your security posture.
RE security: 100% agree with everything you said. This is at the end of the day a security product. Even though we're very early, we've put a ton of thought into the security and especially the cryptography behind our product (e.g. we decided E2EE since the start) and intend on maximizing security posture in the coming months and years ahead — earning trust will definitely be an uphill battle but we hope to do it and have an optimal solution for everyone.
RE SSO: Initially, we started by exploring what other solutions on the market are doing about this and noticed SSO as an enterprise ask even for security products like Bitwarden. That said, I think you have a great point here that I'll discuss with the team: SSO doesn't have to be available/not available across plans but that it could be available across all plans and larger organizations would need to pay for it anyways on the basis of needing it for more users — this preserves the SSO benefit for individuals and small teams as well as enterprises.
PS: I'll work on doing a better job responding to security reports; I appreciate everyone's input a lot in this thread and hope to express that better over writing...
I manage small teams and it would be a requirement for us, and if pricing for a few users is $14/month, normally enterprise is higher than that and an annual commitment, but you wouldn’t be able to get much budget out of me at this moment due to team size, but there is some there.
When choosing tools like this, I pick ones I can grow with so I don’t need to solve it again in the future, so while the team may be small, it can’t adopt it if I cant start from that point.
dubious claim
[1]: https://envkey.com
We're both in the same domain, open-source, and E2EE. Right off the bat, I'd say there are a few key observable differences:
- Infisical is open-source more-or-less from the get go and, as a testament to that, we've grown our community and contributors a lot (50+ now); Envkey was closed-source for a long time before deciding to open-source more recently.
- Infisical is E2EE with opt-out ability so user's can sync secrets directly to cloud platforms like Vercel, Render, GitHub, Netlify, etc. via their APIs; Envkey doesn't have this capability.
- Infisical's client is browser-based; Envkey's is an application you can download back.
Depending on your circumstance and needs, you may find pros and cons for going with either solution.
I will acknowledge that Envkey has been around for much longer, so it may have broader functionality in some respects (e.g. they have SDKs developed across most major languages that we have on our roadmap for the following quarters). Lastly, (small mention) I think that we do care about UI/UX more than a lot of other solutions in the market.
These are just some early thoughts; will add on as more come in.
- The server portion of our v1 was closed source, but all client-side code has been open source all along. Now we're fully open source, as you say.
- Syncing to other platforms can be useful, but apart from breaking end-to-end encryption, it more or less guarantees that you're going to end up with consistency bugs. This is just the nature of failure modes in distributed systems. EnvKey's single source of truth architecture ensures consistency. Config and secrets are always pulled from EnvKey rather than being duplicated across platforms. Also, since all that is needed to integrate with any platform is to set a single environment variable, custom-built integrations are rarely needed (we do have a light-weight one for Heroku, but that's it).
- Browser-based is good for UX and convenience, but it nullifies most of the security benefits of end-to-end encryption. Browser-based end-to-end encryption doesn't protect against attackers or insider threats.
I'd also add that we care a lot about UI and UX as well, but we see our goal as making the best UI and UX that is possible while offering real, uncompromising end-to-end encryption. This does require some UX tradeoffs, but in our view, given the sensitivity the data involved, they are worth it.
We also have a full provider under development here: https://github.com/asheliahut/infisical-provider-terraform
[1] https://github.com/Infisical/infisical/blob/main/docker-comp...
> offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Program or modified version