Generate secure random numbers in mobile apps by using the platform’s cryptographically secure random number APIs, not predictable pseudo-random functions. Use them for secrets, tokens, keys, and session identifiers, and never derive security values from time, device identifiers, or app state. Review code paths that create authentication material to ensure they cannot be replayed or guessed.
Why secure randomness matters in mobile apps
Mobile applications use random values for the same security-critical purposes as backend systems: generating session identifiers, CSRF-style tokens, encryption keys, password reset tokens, one-time codes, and nonce values. If those values are predictable, an attacker can guess, replay, or precompute them, turning a simple implementation choice into account takeover or token forgery.
Platform cryptographic random APIs are designed to draw entropy from trusted operating-system sources and to produce values that are suitable for security decisions. That is why secure randomness is a control, not a convenience feature. It belongs wherever the app creates material that could authorize access, protect data, or establish trust.
Mobile teams should treat random-number generation as part of the app’s security boundary, not as utility code. The same principle applies whether the code runs on iOS or Android, because the risk is not the platform brand but whether the value can be predicted by an attacker who observes the app’s behaviour.
What to use, and what to avoid
Use the platform’s cryptographically secure generator for any value that must remain secret or unguessable. In practice, that means the API specifically intended for security-sensitive randomness, together with secure encoding and appropriate length for the value’s purpose. For broader mobile hardening and testing context, the Mobile App Security Guide is a useful starting point because it ties random value handling to the rest of the mobile attack surface, including secure storage and app verification.
Do not use timestamps, device identifiers, app install counts, user-visible state, or ordinary pseudo-random functions to create secrets. Those sources can be observed, inferred, or repeated, and they often collapse under reverse engineering. If the value protects an authentication flow, assume the attacker will inspect the app and model the generation logic offline.
When randomness is used to generate secrets at build time or in client-side code, test the full path end to end. The output must remain uncorrelated across runs, devices, and sessions, and the application must not cache a value that was meant to be one-time only. If the same generator is used for non-security features like shuffling UI content, keep that separate from the code that creates credentials or tokens.
Where failures show up in real apps
The most common failure is not a broken algorithm, but a misplaced assumption that “random enough” is good enough for security. That mistake often shows up in APIs that return apparently varied values but are still deterministic to a motivated tester. The problem becomes more serious when those values gate login, password reset, link sharing, or signed actions, because the attacker only needs one predictable token to break the flow.
Mobile apps also fail when randomness is generated once and reused across sessions, environments, or users. That can create collisions, enable replay, or make secret material recoverable after app reinstall or device restore. In review, pay special attention to code that uses random output as a seed, wraps it in custom math, or truncates it so aggressively that the effective search space becomes practical.
Good practice is to validate random value generation wherever authentication material is created or refreshed. The more sensitive the value, the less tolerance there is for bespoke logic. If a helper method exists only to avoid calling the platform API directly, that helper deserves scrutiny first.
Risk and Threat Considerations
Poor randomness turns secret creation into guessable pattern generation. In mobile apps, that can expose tokens, session identifiers, reset links, or encryption material to replay and brute-force attacks, especially when the attacker can observe app behaviour or reverse engineer the client.
Failure mechanism: The app substitutes predictable inputs, weak pseudo-random output, or reused values for cryptographically secure entropy, so the attacker can infer or reproduce security values that were meant to be unguessable.
Impact: Authentication flows can be forged, sessions can be hijacked, one-time values can be replayed, and exposed secrets can be abused beyond the mobile app itself.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V9 — Self-contained Tokens | Secure random values underpin unguessable tokens and session material. |
| Recommendation — Use V9 to ensure token generation is cryptographically strong and resistant to prediction. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Randomness quality affects creation and lifecycle of authenticators and secrets. |
| IA-9 — Service Identification and Authentication | Mobile apps often generate secrets used by services, APIs, or non-human actors. | |
| Recommendation — Apply IA-5 to generate and manage authenticators with sufficient entropy and controlled lifecycle. Apply IA-9 when mobile-generated secrets authenticate services, APIs, or workloads. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Cryptographically secure random generation is part of safe cryptographic implementation. |
| Recommendation — Require cryptographically sound randomness wherever cryptography depends on unpredictable values. | ||
| CIS Controls v8 | CIS-3 — Data Protection | Predictable secret generation weakens protection of tokens, keys, and sensitive credentials. |
| Recommendation — Protect secrets by using approved cryptographic randomness for all security-critical values. | ||
Practitioner Guidance
What to verify: Confirm that every security-sensitive random value comes from the platform CSPRNG path, and that no wrapper function reintroduces predictability through seeding, truncation, or custom post-processing. Review both app code and shared SDKs, because inherited helpers are a common place for weak generation to slip in.
Common mistake: Teams often focus on encryption and storage while leaving token generation to utility code. That is backwards, because a perfectly stored secret is still compromised if it was easy to predict when created.
Practitioner takeaway: Treat secure randomness as a prerequisite for trustworthy mobile authentication material, not as an implementation detail, and reject any design that depends on guessing a value being “hard enough” rather than cryptographically unguessable.
Related resources from NHI Mgmt Group
- How can organizations secure their MCP server credentials?
- How should organisations secure mobile identity wallets against tampering and cloned apps?
- What is the difference between secure-as-you-generate and scan-and-fix-later appsec?
- What breaks when mobile banking apps do not use app shielding and secure session controls?