How Password Entropy and Modulo Bias Affect Password Security

For decades, IT departments and corporate password policies instructed employees to create passwords with a specific checklist: at least 8 characters, with one uppercase letter, one number, and one obscure symbol.

The result of this policy was predictable and disastrous: millions of people created passwords like P@ssword1! or Summer2026!. These passwords technically pass corporate complexity rules, yet automated cracking rigs running tools like Hashcat on modern NVIDIA GPUs can crack them in less than three seconds.

To understand why traditional password rules fail, we must look at information theory. In this guide, you will learn how Shannon entropy quantifies password strength, why length exponentially outperforms symbol complexity, and how a subtle mathematical bug known as modulo bias compromises poorly written random password generators.

Shannon Entropy: Measuring Password Unpredictability

In 1948, mathematician Claude Shannon introduced the concept of information entropy. In cryptography, entropy measures how many bits of uncertainty an attacker must overcome to guess an unknown secret through exhaustive search.

For a password where each character is selected uniformly and independently at random from a character pool of size $N$, the entropy $H$ in bits is given by:

$$H = L \cdot \log_2(N)$$

Where:

• $L$ is the total length (number of characters) in the password.
• $N$ is the size of the selectable character set (alphabet pool).
• $\log_2(N)$ represents the entropy contributed by each individual character position.

Character Set Pool Sizes ($N$)

• Numeric only (`0-9`): $N = 10 \implies \log_2(10) \approx 3.32\text{ bits/char}$
• Lowercase letters (`a-z`): $N = 26 \implies \log_2(26) \approx 4.70\text{ bits/char}$
• Alphanumeric (`a-z`, `A-Z`, `0-9`): $N = 62 \implies \log_2(62) \approx 5.95\text{ bits/char}$
• Full Printable ASCII (`a-z`, `A-Z`, `0-9`, symbols): $N = 94 \implies \log_2(94) \approx 6.55\text{ bits/char}$

The Mathematics of Length vs Complexity

Consider a direct comparison between two password generation strategies:

Scenario A: Short and Complex (8 characters, Full ASCII)

• $L = 8$
• $N = 94$
• $H = 8 \times \log_2(94) = 8 \times 6.55 = \mathbf{52.4\text{ bits}}$
• Total Search Space: $94^8 \approx 6.09 \times 10^{15}\text{ combinations}$

An enterprise cracking cluster calculating 100 billion NTLM hashes per second can exhaust this entire search space in under 17 hours.

Scenario B: Longer and Simpler (16 characters, Alphanumeric only)

• $L = 16$
• $N = 62$
• $H = 16 \times \log_2(62) = 16 \times 5.95 = \mathbf{95.3\text{ bits}}$
• Total Search Space: $62^{16} \approx 4.77 \times 10^{28}\text{ combinations}$

That same cracking cluster testing 100 billion combinations per second would require over 150 million years to search this keyspace!

The Mathematical Takeaway: Adding symbols from 62 to 94 adds only $0.60\text{ bits}$ per character. But increasing length from 8 to 16 adds $42.9\text{ bits}$ of entropy, multiplying the attacker's required work by a factor of 7.8 trillion. Length always beats complexity.

The Modulo Bias Trap: How Naive Generators Break Randomness

Even if you configure a generator to produce a 20-character password, the generator itself might be statistically compromised if it uses the remainder operator (%) improperly.

Consider this standard snippet found in thousands of open-source projects:

// WARNING: Flawed implementation suffering from Modulo Bias
function naiveGenerate(length: number, charset: string): string {
  const bytes = new Uint8Array(length);
  crypto.getRandomValues(bytes);
  
  return Array.from(bytes, (byte) => charset[byte % charset.length]).join("");
}

At first glance, this code uses crypto.getRandomValues(), so it looks cryptographically secure. However, it suffers from modulo bias.

Why Modulo Bias Occurs

• A byte generated by crypto.getRandomValues() produces an integer between $0$ and $255$ (256 discrete values).
• Suppose our character set is alphanumeric ($N = 62$).
• Let us divide the total outcomes by the charset size:

$$\frac{256}{62} = 4\text{ with a remainder of } 8\quad (4 \times 62 = 248)$$

Notice what happens when we map integers $0..255$ using byte % 62:

• Characters at indices $0$ through $7$ (0-7 or a-h) are mapped by 5 separate byte values:
• Index 0: 0, 62, 124, 186, 248 (Probability: $\frac{5}{256} \approx 1.953\%$)
• Characters at indices $8$ through $61$ are mapped by only 4 separate byte values:
• Index 8: 8, 70, 132, 194 (Probability: $\frac{4}{256} \approx 1.562\%$)

The first 8 characters in the alphabet are $25\%$ more likely to appear than any other character! To an intelligence agency or password-cracking algorithm with frequency analysis tables, this uneven distribution significantly reduces the effective search entropy.

How UtilityKit Eliminates Bias: Cryptographic Rejection Sampling

To guarantee true uniform randomness, mathematical utilities must employ rejection sampling.

Instead of accepting all 256 byte values, we calculate the largest multiple of our charset size that fits within 256 ($248$). Any random byte equal to or greater than 248 is discarded and repolled:

export function getSecureRandomChar(alphabet: string): string {
  const alphabetLength = alphabet.length;
  // Calculate threshold: largest multiple of alphabetLength <= 256
  const maxValidByte = 256 - (256 % alphabetLength);
  
  const byteBuffer = new Uint8Array(1);
  let randomByte: number;

  do {
    crypto.getRandomValues(byteBuffer);
    randomByte = byteBuffer[0];
  } while (randomByte >= maxValidByte); // Discard biased overshoot bytes

  return alphabet[randomByte % alphabetLength];
}

Because every remaining byte in the range $0..247$ maps to each character in the 62-character alphabet exactly 4 times, every single character has an identical, unbiased probability of $\frac{4}{248} = \frac{1}{62} \approx 1.6129\%$.

Pseudo-Random vs Cryptographically Secure Randomness

A final critical reminder: never use `Math.random()` for passwords, API tokens, or session IDs.

Math.random() in browsers uses algorithms like xorshift128+ or PCG. These are deterministic pseudo-random number generators (PRNGs) designed for high-speed graphics and animations, not cryptography. An attacker observing as few as 2 to 5 consecutive Math.random() outputs can reconstruct the internal state matrix and predict every past and future output!

Always require crypto.getRandomValues() (in browsers) or crypto.randomBytes() / crypto.randomUUID() (in Node.js).

Generate Unbiased, Strong Passwords Instantly

Need to create ultra-secure passwords, passphrases, or API keys? Open UtilityKit's Password Generator.

Our generator uses rejection-sampled crypto.getRandomValues(), provides real-time Shannon entropy ratings, and lets you copy your new credentials securely without storing or transmitting a single character over the network. If you also need system-unique identifiers, check out our UUID Generator.