-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Mark MASTG-TEST-0016 as covered by v2 (by @guardsquare) #3026
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please double check:
- Do we have a new test that tests for "Identify all instances of
SecureRandom
that are not created using the default constructor. Specifying the seed value may reduce randomness." (paragraph 2). If not, we should add one. - Are we using all the links from this test in the new ones?
- https://wiki.sei.cmu.edu/confluence/display/java/MSC02-J.+Generate+strong+random+numbers "Generation of Strong Random Numbers"
- https://wiki.sei.cmu.edu/confluence/display/java/MSC63-J.+Ensure+that+SecureRandom+is+properly+seeded "Proper seeding of SecureRandom"
- https://franklinta.com/2014/08/31/predicting-the-next-math-random-in-java/ "Predicting the next Math.random() in Java"
- Do we have some indication about "You can use @MASTG-TECH-0033 on the mentioned classes and methods to determine input / output values being used.". This may be useful to determine if it's a security-relevant context. Otherwise, we should reverse engineer the code surrounding the found methods to determine if they seem to be used in a security-relevant context. (adding this could be as simple as adding a short paragraph in the Evaluation section of MASTG-TEST-0204)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- The suggestion does not apply anymore. The recent documentation about SecureRandom explains that the provided seed supplements the seed, does not replace it. I was not sure where to document this.
- Will add the missing ones.
- Will adjust
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After checking, both CMU links (which I did not include) are currently very outdated, and their recommendations do not apply anymore. I am mentioning one of them in the mitigations, but tbh even there some of the recommendations are slightly incorrect.
Reviewer suggestions Co-authored-by: Carlos Holguera <[email protected]>
The default [no-argument constructor of `SecureRandom`](https://wiki.sei.cmu.edu/confluence/display/java/MSC02-J.+Generate+strong+random+numbers "Generation of Strong Random Numbers") is usually recommended for generating secure random values, as it uses the system-specified seed value to generate a 128-byte-long random number. | ||
|
||
Providing an hard coded seed to the constructor of `SecureRandom` is [discouraged in Android Documentation](https://developer.android.com/privacy-and-security/risks/weak-prng?source=studio#weak-prng-java-security-securerandom), as it may lead to introducing deterministic behavior of `SecureRandom` in some implementations. | ||
`SecureRandom` documentation explains that [the provided seed supplements, rather than replacing the existing seed](https://developer.android.com/reference/java/security/SecureRandom?hl=en#setSeed(byte[])), but this may not apply if an [old security provider](https://android-developers.googleblog.com/2016/06/security-crypto-provider-deprecated-in.html) is being used. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I included this to cover for this weird corner case, so that the mitigation explains all the relevant points.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few typo/grammer fixes
Co-authored-by: Jeroen Beckers <[email protected]>
Thank you for submitting a Pull Request to the OWASP MASTG. Please make sure that:
This PR closes #2947.