The Guide to Secure Passwords: Size Matters

1. The Thermodynamics of Brute Force: The Physics of Cracking

The modern digital landscape is no longer a playground for the intellectually curious; it is a battleground defined by the cold, hard thermodynamics of computational power. In the domain of information security, specifically regarding authentication and credential guarding, the adversary is not a human being sitting at a keyboard making educated guesses. The adversary is a mathematical engine, a relentless thermodynamic process designed to exhaust the probability space of your secrets. The security of a password is not defined by its cleverness, its linguistic flair, or its mnemonic utility. It is defined strictly by the amount of energy and time required to locate it within a mathematical search space.

We are currently witnessing a paradigm shift in the economics of brute-force attacks. This shift is driven by the commoditization of high-performance computing, specifically the evolution of the Graphics Processing Unit (GPU). The NVIDIA RTX 4090 is not merely a consumer device for rendering video games; it is a weaponized mathematical accelerator. Its architecture, designed for massive parallelism, happens to be perfectly optimized for the bitwise operations that constitute cryptographic hashing.

When we scale this to a cluster—a standard configuration for password cracking rigs—the numbers become incomprehensible to the human mind. An eight-card cluster of RTX 4090s pushes this throughput into the Terahash range. At these speeds, the concept of "time" changes. We are no longer talking about years or months. We are talking about milliseconds.

The physics of this attack vector are rooted in the architecture of the GPU. Unlike a Central Processing Unit (CPU), which is designed for serial processing and complex logic branching (making it a "Ferrari" that can drive fast but only carry a few passengers), a GPU is a massive array of thousands of smaller, simpler cores (a fleet of 10,000 buses). For password cracking, we do not need complex logic. We need to perform the same simple mathematical operation (hashing) on billions of different inputs simultaneously. This is an "embarrassingly parallel" problem. The RTX 4090, with its 16,384 CUDA cores, can theoretically check tens of thousands of passwords in a single clock cycle.

This commoditization of power renders traditional advice obsolete. We have told users for decades to "make it complex." We told them to replace 'a' with '@' and 'i' with '1'. This advice, often referred to as "Leetspeak," is a dangerous myth in the face of modern hardware. If the password is short—standard 8 characters—complexity is irrelevant. The mathematical space of an 8-character password, even utilizing every printable ASCII character, is roughly $6.6\times {10}^{15}$ combinations. To a human, that is a vast number. To a cluster of RTX 4090s running Hashcat, that is an afternoon's work.

1.1 The Evolution of Hashcat and Hardware

The tool of choice for this thermodynamic assault is Hashcat, widely acknowledged as the world's fastest password cracker. Hashcat is a specialized piece of software that interfaces directly with the GPU hardware, bypassing the operating system's graphical layers to run raw OpenCL or CUDA code.

The evolution of Hashcat mirrors the evolution of the hardware itself.

• CPU Era: Early cracking was done on CPUs. It was slow.
• GPU Era: The introduction of programmable shaders allowed hackers to offload math to the graphics card.
• ASIC/FPGA Era: Specialized hardware (Application Specific Integrated Circuits) exists for specific algorithms (like Bitcoin mining), but for general password cracking, high-end consumer GPUs remain the sweet spot of flexibility and raw power.

The latest benchmarks for the RTX 4090 reveal the terrifying efficiency of this software-hardware pairing.

• MD5: A legacy hashing algorithm still shockingly prevalent. A single RTX 4090 hits ~163.4 GH/s.
• SHA-1: Another deprecated but common algorithm. Speed: ~58.5 GH/s.
• SHA-256: The standard for modern security (and Bitcoin). Speed: ~21.7 GH/s.
• NTLM: The Windows logon hash. Speed: ~285.8 GH/s.

Note the disparity. NTLM is broken at speeds ten times faster than SHA-256. This is because NTLM (based on MD4) requires fewer bitwise operations per hash. This physics dictates that Windows passwords must be significantly longer than web passwords to offer the same level of time-based security.

1.2 The Myth of Complexity

Why is "complexity" a myth? Because it addresses the wrong variable in the entropy equation. Complexity increases the density of the search space (the number of options per slot), but it does not change the dimensionality (the number of slots).

When a user changes password to P@ssword!, they believe they have outsmarted the hacker. In reality, they have simply moved from a dictionary attack to a rule-based attack. Hashcat has a "Best64" rule set—a list of the 64 most common transformations humans apply to passwords. Capitalizing the first letter is Rule #1. Appending a digit is Rule #2. Replacing 'a' with '@' is Rule #3.

An RTX 4090 does not care if you added a symbol. It consumes the "complex" password just as easily as the simple one, provided the length is short. The computational cost of checking the symbol set is negligible compared to the exponential cost of adding length.

2. The Mathematics of Entropy (The PhD Section)

To understand why length is the only metric that matters, we must abandon qualitative descriptions and embrace Information Theory. Security is not a feeling; it is a quantity. That quantity is Entropy, measured in bits.

Entropy quantifies the uncertainty inherent in a random variable. In the context of passwords, it represents the minimum number of bits required to encode the total number of possible passwords in the search space. It is a measure of the "work" an attacker must perform.

2.1 The Fundamental Formula

The entropy (E) of a password generated by a truly random process is determined by the size of the character set (N) and the length of the password (L).

The formula is derived from the Hartley Entropy equation:

Where:

• E is the Entropy in bits.
• L is the Length of the password (number of characters).
• N is the Cardinality of the Character Set (the pool of unique symbols available).

This equation reveals the fundamental asymmetry of password strength.

• N (Character Set) is inside the logarithm. Increasing N yields diminishing returns.
• L (Length) is the multiplier. Increasing L yields linear growth in bits, which translates to exponential growth in the Search Space (S).

The Search Space (S) is the total number of permutations:

2.2 The Proof: Exponential vs. Linear Scaling

Let us mathematically prove why adding length is superior to adding complexity.

Baseline:

Assume a password of length L = 8 using only lowercase letters (N = 26).

Experiment A: Increasing Complexity (The "Special Character" Approach)

We instruct the user to use uppercase letters, numbers, and symbols (N = 95). We keep the length at 8.

Experiment B: Increasing Length (The "Passphrase" Approach)

We instruct the user to keep using only lowercase letters (N = 26) but we increase the length to 12.

Comparison: Even though Experiment A used a much richer alphabet (95 symbols vs 26), Experiment B is stronger. The search space of the 12-character lowercase password is roughly 14 times larger than the 8-character complex password.

Now, consider the TrueRNG approach: High Complexity (N = 95) AND High Length (L = 16).

The difference between 52 bits and 105 bits is not "double." It is a logarithmic scale. 105 bits is 2⁵³ times stronger than 52 bits. 2⁵³ ≈ 9,000,000,000,000,000. The 16-character password is nine quadrillion times harder to crack than the 8-character complex password. This is the proof. Mathematical scaling heavily favors the exponent (L) over the base (N).

2.3 Visualizing Entropy: The Security Cliff

To visualize this, imagine a bar chart representing the bit-strength of various password strategies. The "Security Cliff" is the threshold where brute force becomes impossible.

• P@ssword1 (8 chars): This bar is barely visible. Due to dictionary rules, its effective entropy is near zero. Even treated as random, it sits at ~50 bits.
• correct-horse-battery-staple (4 words): Popularized by XKCD. Assuming a dictionary of 2048 words, the entropy is log₂(2048⁴) = 44 bits. This is surprisingly low and vulnerable to modern GPU clusters.
• TrueRNG (16 chars): This bar towers over the others. At 105 bits, it exceeds the "NIST Recommendation" and enters the realm of cryptographic keys.

This visual demonstrates that while "Passphrases" (XKCD style) are better than "Password123", they often fail to reach high entropy unless 5, 6, or 7 words are used. Random alphanumeric strings generated by TrueRNG are the most efficient way to achieve high entropy per character.

3. The "Time to Crack" Analysis (Table)

Theory is necessary, but kinetics are persuasive. We must translate "bits" into "time." How long does it actually take an attacker to break these passwords using the hardware described in Section 1?

For this analysis, we assume an attacker possesses an 8-GPU Cluster of NVIDIA RTX 4090s.

• Target Hash: NTLM (Windows Authentication). This is chosen because it is fast to crack and critical for corporate security.
• Combined Hash Rate: Approx. 2,200 GH/s (2.2 × 10¹² hashes per second).
• Formula: We assume the password is found, on average, halfway through the search:

4. The Solution: CSPRNG vs. Human Bias

If length is the shield, then randomness is the structural integrity of that shield. A 16-character password is useless if the characters are predictable. This brings us to the critical distinction between Pseudo-Randomness, Human Randomness, and True Randomness.

4.1 The Failure of Human "Randomness"

The human brain is an excellent pattern recognition machine, which makes it a terrible random number generator. When we attempt to create randomness, we invariably create structure.

• Keyboard Walks: Analysis of millions of breached passwords reveals that humans heavily rely on the geometry of the keyboard. Patterns like qwert (top left), asdfg (middle left), and xcvbn (bottom left) appear millions of times.
• Regional Bias: In France, the pattern is azerty; in Germany, qwertz. Attackers know this. They do not just brute force; they "toggle" keyboard layouts in their attack profiles.
• Distribution Bias: When asking a human to type a random string, they will almost never type aa or 77. We perceive repetition as "not random," even though true randomness dictates that repetitions must occur. By avoiding repetition, we reduce the search space, aiding the attacker.
• Semantic Anchors: We anchor our passwords to reality. "2024" and "2025" are currently the most dangerous substrings to include in a password. They allow attackers to mask the last 4 digits of a password with 100% certainty.

4.2 The Trap of Math.random()

For developers building password generation tools, the temptation is to use the built-in JavaScript function Math.random(). This is catastrophic.

• The Mechanism: In V8 (Chrome/Node.js), Math.random() uses an algorithm called xorshift128+. This is a Pseudo-Random Number Generator (PRNG).
• The Flaw: PRNGs are deterministic. They start with a "seed" and produce a sequence of numbers based on math. If you know the seed (often the current time) or if you can observe a sequence of outputs, you can calculate the internal state of the generator.
• The Exploit: Once the state is known, the attacker can predict every future number the generator will produce. If you use Math.random() to generate a user's session ID or password, an attacker can generate the exact same password on their machine.

4.3 The Gold Standard: CSPRNG via TrueRNG

To defeat the GPU, we need Cryptographically Secure Pseudo-Random Number Generators (CSPRNG). In the browser and Node.js, this is accessed via crypto.getRandomValues().

The TrueRNG device feeds physical noise into the OS kernel's entropy pool. When you call crypto.getRandomValues(), you are effectively pulling bits derived from quantum chaos. This is nondeterministic. Even if an attacker has the same device, they cannot reproduce your noise.

5. Implementation: Secure Password Generator Code

Generating a secure password is not as simple as picking random characters. A naive implementation introduces Modulo Bias, a subtle statistical flaw that compromises high-security environments.

5.1 Understanding Modulo Bias

Suppose we have a character set of 62 symbols. We generate a random byte (0-255) and map it to a character using the modulo operator: index = random_byte % 62. A byte has 256 values. 256 ÷ 62 = 4 with a remainder of 8. This means the first 8 characters of our set will be mapped to by 5 byte values, while the rest are mapped to by only 4.

Result: The first 8 characters are 25% more likely to appear than the others. Over a 16-character password, this bias accumulates, significantly reducing the effective entropy.

5.2 The Solution: Rejection Sampling

To fix this, we use Rejection Sampling. We calculate a "limit"—the largest multiple of our character set size that fits within 256. If we generate a random byte that falls above this limit (into the "remainder zone"), we simply reject it and generate a new one. This ensures that every character in our set has an exactly equal probability of being chosen.

/**
 * GENERATE SECURE PASSWORD (TrueRNG Compatible Logic)
 * Uses CSPRNG (crypto.getRandomValues)
 * Implements Rejection Sampling to eliminate Modulo Bias.
 */
function generateSecurePassword(length = 32) {
  // 1. Define the Character Set (N=94 printable ASCII)
  const charset = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789!@#$%^&*()-_=+{};:,.<>?";
  const charsetLength = charset.length;

  // 2. Calculate the 'Limit' for Rejection Sampling
  // 256 / 94 = 2.72 -> max factor is 2. Limit = 2 * 94 = 188.
  const limit = 256 - (256 % charsetLength);

  let password = "";
  const randomBuffer = new Uint8Array(1);

  // 3. Generate Random Bytes using CSPRNG
  while (password.length < length) {
    window.crypto.getRandomValues(randomBuffer);
    const randomByte = randomBuffer[0];

    // 4. Rejection Sampling Check
    if (randomByte < limit) {
      password += charset[randomByte % charsetLength];
    }
  }
  return password;
}