Secure Random Generation: Why Math.random() is Broken

The Fatal Security Flaw in Math.random()

One of the most persistent vulnerabilities in modern web applications is the misuse of Math.random() for generating session tokens, verification codes, reset links, and temporary passwords.

The ECMAScript specification explicitly notes:

"Math.random() does not provide cryptographically secure random numbers. Do not use them for anything related to security."

Under the hood, modern V8 (Google Chrome, Node.js) and JavaScriptCore (Safari) engines implement xoroshiro128+ or xorshift128+ for Math.random(). These algorithms are optimized purely for mathematical simulation speed, not unpredictability. An attacker observing just 2 to 3 consecutive generated floating-point numbers can reconstruct the internal 128-bit internal register state in less than 20 milliseconds, successfully anticipating all subsequent passwords or tokens.

Cryptographically Secure Pseudo-Random Number Generators (CSPRNG)

To be classified as cryptographically secure, an algorithm must satisfy two strict criteria:

1. Next-Bit Unpredictability: Given knowledge of the first $k$ bits of a random sequence, there is no polynomial-time algorithm that can predict the $(k+1)$-th bit with probability greater than 50%.
2. State Compromise Extension: Even if an adversary discovers the current internal state of the generator, they cannot reconstruct any historical sequence of outputs generated prior to the compromise.

The W3C Web Cryptography Standard

In modern client-side software, cryptographically secure random bytes are sourced directly from the host kernel via the W3C Web Cryptography API:

// Correct client-side secure random byte generation
const buffer = new Uint32Array(16); // 16 32-bit unsigned integers (512 bits of entropy)
window.crypto.getRandomValues(buffer);

The operating system collects entropy from physical non-deterministic events: thermal sensor fluctuations, CPU clock drift, network packet inter-arrival timings, and device driver interrupts.

The Mathematics of Password Entropy

Entropy measures the degree of unpredictability or uncertainty in an information source. In information theory, password entropy is quantified in bits using Shannon's entropy formula:

H = L × log2(R)

Where:

• H: Entropy measured in bits.
• L: Password length (number of characters).
• R: Size of character pool from which each character is independently sampled.

Comparing Character Pools and Brute-Force Feasibility

Character Set Pool (R)	Pool Size	Entropy/Char	12-Char Entropy	16-Char Entropy
Numbers Only (0-9)	10	3.32 bits	39.8 bits (Trivial)	53.1 bits (Weak)
Lowercase Letters (a-z)	26	4.70 bits	56.4 bits (Moderate)	75.2 bits (Strong)
Alphanumeric (a-z, A-Z, 0-9)	62	5.95 bits	71.4 bits (Strong)	95.2 bits (Ultra-Secure)
Full ASCII Symbols (Keyboard)	94	6.55 bits	78.6 bits (Military-Grade)	104.8 bits (Unbreakable)

Brute-Force Timeline: The Threat of Modern ASIC Clusters

Modern specialized GPU clusters (such as an 8x NVIDIA RTX 4090 rig) can evaluate over 100 billion NTLM hashes per second.

A 10-character lowercase password ($26^{10} approx 1.41 imes 10^{14}$ combinations) can be exhausted in approximately 23 minutes. In contrast, a 16-character full-symbol password ($94^{16} approx 3.7 imes 10^{31}$ combinations) would require more than 1.17 trillion years to crack by exhaustive search.