Randomness is one of those details that is invisible until it is exploited. If your app generates a security-sensitive value, a token, a session identifier, a nonce, a password-reset code, with an ordinary random function, those values can be predictable, and a predictable token is a guessable one. The fix is small but specific: use the platform's cryptographically secure random generator for anything security-relevant, and never the general-purpose one. Here is where randomness matters, the difference between insecure and secure generators, and how to get it right.
Short answer
Using a non-cryptographic random source, like a general-purpose random function, for security-sensitive values makes those values predictable, which can lead to guessable tokens, session identifiers, or codes and, in turn, account takeover. Per OWASP MASVS, you must use a cryptographically secure random generator for any security purpose: SecureRandom on Android, and SecRandomCopyBytes or the system secure random on iOS. The general-purpose random functions are for non-security uses like shuffling or sampling, not for tokens, keys, nonces, or initialization vectors. So reach for the platform's secure random whenever the value protects something, and keep the ordinary random for everything else.
What you should know
- Non-cryptographic random is predictable: unsuitable for security values.
- Predictable tokens are guessable: which can enable account takeover.
- Use a secure random generator: SecureRandom or the platform secure random.
- Security values need it: tokens, session IDs, nonces, keys, IVs, codes.
- General-purpose random is for non-security: shuffling, sampling, and the like.
Where does randomness matter for security?
Anywhere a value needs to be unguessable. Security-sensitive random values include session identifiers, authentication and password-reset tokens, one-time codes, cryptographic keys, nonces, and initialization vectors, and what they have in common is that an attacker who can predict or reproduce the value defeats the protection it provides. A predictable session identifier can be guessed to hijack a session; a predictable reset token can be guessed to take over an account; a predictable nonce or initialization vector can weaken your encryption. By contrast, plenty of randomness in an app is not security-relevant, choosing a random tip to display, shuffling a list, picking a sample, and there the ordinary random function is fine. The distinction is whether guessing the value would let someone bypass a control, and if it would, the value must be unpredictable.
Insecure versus secure random generators
The difference is whether the output can be predicted. The table contrasts them.
| Generator | Use |
|---|---|
| General-purpose random | Non-security: shuffling, sampling, display choices |
| Android SecureRandom | Security values on Android |
| iOS SecRandomCopyBytes or system secure random | Security values on iOS |
| Predictable or fixed seed | Never for security; reproducible output |
General-purpose random functions are designed to be fast and statistically uniform, not unpredictable, and their output can often be reproduced or predicted by an attacker who learns the algorithm and a little state. A cryptographically secure random generator is designed so its output cannot be predicted even with knowledge of previous outputs, which is exactly the property a security value needs. Seeding a secure generator with a predictable or fixed seed undermines it, so let the platform seed it from the system entropy rather than supplying your own.
How do you generate secure random values?
Use the platform's cryptographically secure generator, correctly seeded. On Android, use SecureRandom to produce tokens, keys, nonces, and identifiers, and let it seed itself from the system rather than providing a fixed seed. On iOS, use SecRandomCopyBytes or the system secure random source for the same purposes. Generate values with enough length to resist guessing, since a short random value is still brute-forceable even if the generator is strong. Where the value is created on your server, like a session token, ensure the server uses a secure generator too. And keep the general-purpose random for the non-security uses where speed matters and predictability does not. The rule is simple: if guessing the value would compromise security, generate it with the platform's secure random, of adequate length, seeded by the system.
What to watch out for
The first trap is using a general-purpose random function for a token, session identifier, or code, which produces predictable values an attacker can guess; use the secure generator. The second is seeding a secure generator with a fixed or predictable seed, which removes its unpredictability; let the system seed it. The third is a value that is random but too short to resist brute force; use adequate length. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled APK, AAB, or IPA against OWASP MASVS and assesses cryptographic and randomness usage, which helps you catch an insecure random source used for a security value before you ship. The generator choice you make in your code.
What to take away
- Using a non-cryptographic random source for security values makes them predictable, which can lead to guessable tokens and account takeover.
- Use a cryptographically secure random generator, SecureRandom on Android, SecRandomCopyBytes or the system secure random on iOS, for tokens, keys, nonces, IVs, and codes.
- Keep the general-purpose random for non-security uses, let the system seed the secure generator, and use adequate length so values resist brute force.
- Use a pre-submission scan such as PTKD.com to catch an insecure random source used for a security value before you ship.
