You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
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 ofjava.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.Beta Was this translation helpful? Give feedback.
All reactions