Clarify guidelines for appropriate RNGs

[praetorian-peter-mueller]

Bottom Line

I recommend that we add language to MASTG-TEST-0016 to provide guidance to Android security engineers using languages other than Java. I propose that when java.security.SecureRandom is not available due to the choice of language, the language in MASTG-TEST-0016 should require that a "cryptographically secure pseudorandom number generator" should be used instead.

Details

The Static Analysis section in MASTG-TEST-0016 asks testers to look for custom or known-insecure random number generators. The present language provides an example of an insecure RNG in java.util.Random, and instead suggests the use of java.security.SecureRandom with the default constructor. This is very helpful information when the app in question is developed in Java.

Some Android apps are not written in Java (e.g., Dart), and in cases like these, it may be helpful for testers to have some other concise criteria for a "sufficiently secure" RNG.

I believe the right answer here is for developers to consult the standard library documentation (or equivalent) for their programming language and/or their operating system's developer documentation and identify the package, library, or device that exposes the kernel's cryptographically secure pseudorandom number generator (kernel-based CSPRNG). This should be the default choice for RNGs being used for security-sensitive purposes unless there is a compelling reason to the contrary.

Most modern programming languages and operating systems recommend a specific choice of CSPRNG in their documentation, and including the specific wording "cryptographically secure pseudorandom number generator" in MASTG-TEST-0016 will help the reader understand what to search for in their documentation.

Conclusion

MASTG-TEST-0016 should be updated to recommend the use of a "cryptographically secure pseudorandom number generator" when java.security.SecureRandom is not available due to the choice of language.

[sushi2k]

Thank you for raising this @praetorian-peter-mueller! As part of the refactoring that was starting last year and the introduction of our MASWE's this should be addressed in the weaknesses: https://mas.owasp.org/MASWE/MASVS-CRYPTO/MASWE-0027/#mitigations

Let me know if this resolves your request.

[cpholguera]

Thanks @praetorian-peter-mueller! I encourage you to check out the new v2 beta tests instead, as we no longer maintain the v1 tests. In this case:

• https://mas.owasp.org/MASTG/tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0204/
• Which refers to best practices: https://mas.owasp.org/MASTG/best-practices/MASTG-BEST-0001/

Please check both links as well as the MASWE-0027 provided by Sven and let us know if you're still missing something.

I'd also like to encourage you to help us port the v1 tests. You can find the relevant GitHub issues in our milestones:

https://github.com/OWASP/owasp-mastg/milestones

If you have any questions, please let us know.