5 ms·

Hi. I'm also working on an E2E secrets manager. https://github.com/purton-tech/cloak https://github.com/purton-tech/cloak A few tips. 1. It looks like I'm abl

Hi. I'm also working on an E2E secrets manager. https://github.com/purton-tech/cloak https://github.com/purton-tech/cloak 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/ 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.

vmatsiiako 4y ago
Thank you for pointing this out! Happy to take a look and discuss what you're building! I agree with some of these tips, but I think it's best to report them privately to team@infisical.com. We can then see with our team if these points are correct. Otherwise, this goes against responsible practices of security notifications and sounds more like an ad for your project.
- pc86 4y ago
  Wow, this comment is more than enough to make sure I never use your product.
- ianpurton 4y ago
  OK. I'll stop looking now. However if you do require a security review then I would be happy to oblige.
- sveme 4y ago
  You open-sourced your code - isn't this scrutiny exactly what you would want to achieve? Alternatively, I would expect these reports to be reported via your issues tracker.
  - dangtony98 4y ago
    Yup! 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.
    - whylo 4y ago
      > employ a security policy of reporting any security concerns via email You don't have a security.txt, https://infisical.com/docs/security/overview 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/new 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 https://github.com/Infisical/infisical/security/policy
      - dangtony98 4y ago
        There are 3 different locations in the GitHub repo regarding the security policy: a SECURITY.md file containing instructions to report security vulnerabilities to team@infisical.com — this is employed in other open core repos like Strapi, PostHog, Chatwoot; a security policy on the sidebar that links to the SECURITY.md; and a security section in our README that also links to the SECURITY.md. 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!
    - 1ba9115454 4y ago
      Standard practice is to do a full security audit before you onboard customers.
- camjw 4y ago
  > sounds more like an ad for your project I feel like somehow your response is the opposite of an ad for your project.
- JoBrad 4y ago
  I took it as establishing credentials. They didn’t compare your project to their’s, and they offered helpful alternatives.
dangtony98 4y ago
Ack. Thanks for the points. Un-packing a few things: 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-security/token-storage 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-cryptography-with-passwords/ 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!
- Hansenq 4y ago
  Check out https://socket.dev/ https://socket.dev/ Been super impressed by their approach to identifying and securing codebases against supply chain attacks (and I believe they have a special deal for open source repos too!)
  - dangtony98 4y ago
    Just added it to my bookmarks — Will be checking it out thanks! I wonder how this compares to Snyk, also in the area of securing against supply chain attacks.
chromatin 4y ago
Feedback on Cloak: 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.
- ianpurton 4y ago
  Thanks. I'll take a look at that.

vmatsiiako 4y ago

Thank you for pointing this out! Happy to take a look and discuss what you're building! I agree with some of these tips, but I think it's best to report them privately to team@infisical.com. We can then see with our team if these points are correct. Otherwise, this goes against responsible practices of security notifications and sounds more like an ad for your project.

pc86 4y ago
Wow, this comment is more than enough to make sure I never use your product.
ianpurton 4y ago
OK. I'll stop looking now. However if you do require a security review then I would be happy to oblige.
sveme 4y ago
You open-sourced your code - isn't this scrutiny exactly what you would want to achieve? Alternatively, I would expect these reports to be reported via your issues tracker.
- dangtony98 4y ago
  Yup! 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.
  - whylo 4y ago
    > employ a security policy of reporting any security concerns via email You don't have a security.txt, https://infisical.com/docs/security/overview 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/new 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 https://github.com/Infisical/infisical/security/policy
    - dangtony98 4y ago
      There are 3 different locations in the GitHub repo regarding the security policy: a SECURITY.md file containing instructions to report security vulnerabilities to team@infisical.com — this is employed in other open core repos like Strapi, PostHog, Chatwoot; a security policy on the sidebar that links to the SECURITY.md; and a security section in our README that also links to the SECURITY.md. 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!
  - 1ba9115454 4y ago
    Standard practice is to do a full security audit before you onboard customers.
camjw 4y ago
> sounds more like an ad for your project I feel like somehow your response is the opposite of an ad for your project.
JoBrad 4y ago
I took it as establishing credentials. They didn’t compare your project to their’s, and they offered helpful alternatives.

dangtony98 4y ago

Ack. Thanks for the points. Un-packing a few things: 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-security/token-storage 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-cryptography-with-passwords/ 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!

Hansenq 4y ago
Check out https://socket.dev/ https://socket.dev/ Been super impressed by their approach to identifying and securing codebases against supply chain attacks (and I believe they have a special deal for open source repos too!)
- dangtony98 4y ago
  Just added it to my bookmarks — Will be checking it out thanks! I wonder how this compares to Snyk, also in the area of securing against supply chain attacks.

chromatin 4y ago

Feedback on Cloak: 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.

ianpurton 4y ago
Thanks. I'll take a look at that.