Insecure random values should be opt-in
See original GitHub issueRight now, this module will automatically fall back to Math.random()
in browser environments that don’t support CSPRNG use, essentially failing open.
To operate securely, it should instead fail hard with an error, and only allow falling back to an insecure random source if the developer explicitly indicates that this is acceptable.
Issue Analytics
- State:
- Created 7 years ago
- Reactions:29
- Comments:21 (11 by maintainers)
Top Results From Across the Web
Insecure Randomness - OWASP Foundation
Insecure randomness errors occur when a function that can produce predictable values is used as a source of randomness in security-sensitive context. Computers ......
Read more >Is it acceptable to use rand() for cryptographically insecure ...
If you want "randomness" but don't care for cryptographically secure, then yes rand is fine. – Irelia. Sep 23, 2019 at 17:15. 7....
Read more >Insufficient Entropy For Random Values - PHP Security
Generating high quality, i.e. extremely difficult to guess, random values is important. Allowing password reset tokens, CSRF tokens, API keys, nonces and ...
Read more >CWE-330: Use of Insufficiently Random Values
The software uses insufficiently random numbers or values in a security context ... For a value to be cryptographically secure, it must be...
Read more >Secure Randomness in PHP - Soliant Consulting
If PHP 7 is not an option and you don't have mcrypt or if you don't want bytes and want a random number...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I actually feel like this is a pretty legitimate request. Most devs aren’t aware of the security issues of less-than-crypto-quality PRNGs. Requiring them to opt-into the existing possibly-insecure behavior is probably a good thing.
… in the next major version, though.
Reopen?
While I understand your point, I think the current behavior is more developer friendly and since this module isn’t even aiming for strong crypto I feel less strongly that this is a real problem.