Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cryptographically Weak PRNG #15

Closed
Berkmann18 opened this issue Jul 23, 2018 · 3 comments
Closed

Cryptographically Weak PRNG #15

Berkmann18 opened this issue Jul 23, 2018 · 3 comments

Comments

@Berkmann18
Copy link

After running security audits (npm audit) on some projects I found out that packages such as jest-cli had this vulnerability due to this package.
It can be explained here: https://nodesecurity.io/advisories/157.

@jonschlinkert
Copy link
Owner

  1. Please only create one issue, on one repository.
  2. Please follow responsible disclosure and don't ever create issues about security or vulnerabilities. Please close the other issues.
  3. There is not now, and never was a vulnerability in this library. We added a feature to allow users to choose a more cryptographically secure function for generating random strings.
  4. Prior to that, this library did nothing at all related to that. It was for generating pseudo-random strings for things like folder names and test fixtures. We never mentioned anything related to passwords or API tokens, and no one was using it for anything like that, given that the library had something like 3 or 4 dependents before the latest major release.

@Berkmann18
Copy link
Author

Berkmann18 commented Jul 26, 2018

  1. There wre no open issues about this still problematic issue.
  2. Some of the other issues aren't of my doing especially when this package is used by a few widely used packages and that I'm not the first one to the "call".
  3. How come NPM (technically NSP and apparently also Snyk) treat that as a genuine vulnerability?
    I'm not saying it's bad to allow users to choose functions for generating random strings but it appears that the default one or something is too vulnerable.
  4. What guarantee do you have that no malicious person would exploit your code for passwords/tokens or whatever other reason?

I'm not a NSP/NPM security staff but there's surely a reason why the audits traced back to this package which lead in having this same vulnerability flagged more than enough on a few packages.

And before you jump at me for trying to help and having fewer people annoyed by the propagative warnings, you should perhaps speak to the person who audited your package and generated the audit 157.
It would be irresponsible to ignore and not do anything when there's supposedly something concerning.

@xehpuk
Copy link

xehpuk commented Oct 9, 2018

Please follow responsible disclosure […]

The advisory was published on April 14, 2017. This issue was created on July 23, 2018. I don't see any disclosure here?

We added a feature to allow users to choose a more cryptographically secure function for generating random strings.

Why did you see the need to add this "feature"? If this library is never ever to be used in a context where security is important, isn't this simply a performance penalty?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants