MyToolsList

How to Generate a Strong Password (the Secure Way)

How to Generate a Strong Password in 2024: A Complete Guide

The average user has 100+ online accounts by 2024. Each password manager entry is a single point of compromise — and a weak password is the most common attack vector in every published breach dataset (Verizon DBIR 2024, NIST SP 800-63B). This guide covers the only reliable modern methods to generate cryptographically strong passwords, the math behind entropy, why "complexity rules" are outdated (and what replaced them in NIST's 2024 Draft Rev 4 update), and the specific pitfalls of browser-based password generators that compromise security.

Table of Contents

  1. What Makes a Password "Strong" in 2024
  2. The Math: Entropy, Bits, and Brute-Force Resistance
  3. NIST SP 800-63B Password Guidelines
  4. Step-by-Step: Generate a Cryptographically Strong Password
  5. Password Manager vs. Memorized: Two Different Categories
  6. Pitfalls of Online Password Generators
  7. Browser-Based Generation: crypto.getRandomValues() vs Math.random()
  8. How Long Will Your Password Resist a Brute-Force Attack?

What Makes a Password "Strong" in 2024 {#what-it-is}

Strong passwords in 2024 are characterized by:

  • Sufficient entropy (measured in bits): at least 60 bits for low-value accounts, 80+ bits for high-value, 128+ bits for cryptographic keys.
  • Uniqueness per service: no reuse. Verizon DBIR 2024 reports credentials involved in roughly 36% of breaches, with credential stuffing and reuse being the dominant vector among credential-related breaches.
  • Not derived from public information: no pet names, birthdates, phone numbers, sports teams. All these are crackable via targeted dictionaries within minutes.
  • Stored in a password manager, not memorized — for all accounts except the password manager's master password itself.

The 2024 NIST password guideline update (Draft SP 800-63B Revision 4, 2024) explicitly drops the long-standing "must have uppercase + lowercase + digit + symbol" requirement (which produced Password1! patterns) in favor of length-focused rules. NIST also deprecated periodic mandatory password changes — the practice that causes users to increment Password2024! to Password2025!, a pattern that brute-force dictionaries now target.

The Math: Entropy, Bits, and Brute-Force Resistance {#entropy-math}

Password entropy is measured in bits: each bit doubles the work a brute-force attacker must do.

| Effective Symbol Pool | Per-symbol bits | |---|---| | Lowercase letters (26) | ~4.70 bits | | Add uppercase (52) | ~5.70 bits | | Add digits (62) | ~5.95 bits | | Add symbols (95, full ASCII printable) | ~6.57 bits | | Full Unicode (effectively unlimited) | varies |

Total bits ≈ length × per-symbol bits. A 16-character password from a 95-symbol pool has ~105 bits of entropy. A 20-character password from the same pool has ~131 bits. The relationship is roughly:

| Password | Approx. Bits | Brute-Force Time (offline GPU 2024) | |---|---|---| | password123 | ~30 bits | seconds | | Password1! | ~36 bits | minutes | | correct-horse-battery-staple (4 random words) | ~44 bits | days | | 14-char random alphanumeric | ~84 bits | ~3.8 million years (single GPU) | | 16-char random from 95-symbol pool | ~105 bits | centuries of centuries | | 20-char random from 95-symbol pool | ~131 bits | longer than universe age |

Modern recommendation: aim for ≥80 bits, which on a 95-symbol pool is ~13 characters. On a 65-symbol pool (alphanumeric + symbols) is ~14 characters.

The math assumes the password generator is truly random. If it uses Math.random() (a non-cryptographic PRNG), an attacker can replicate the seed after observing a few outputs and predict the password. Cryptographic password generators use crypto.getRandomValues() (Web Crypto API) or crypto.randomBytes() (Node.js), both of which pull entropy from OS-level hardware noise (timing of disk reads, mouse movements, CPU jitter).

NIST SP 800-63B Password Guidelines {#nist}

NIST's primary published password document is SP 800-63B Revision 3 (2017), with an ongoing Draft Revision 4 (2024) currently under public comment. The 2024 update reflects ~15 years of breach-data analysis: complexity requirements (symbol + number + uppercase) produce predictable patterns (Password1!) that attackers' dictionaries now contain as entries. Length with no other constraint produces longer passwords from pure random with higher effective entropy.

Rev 4's key password-composition changes:

  1. Minimum 8 characters (no maximum recommended; longer is better).
  2. No mandatory character class requirements (no "must include symbol" rules — replaced by length).
  3. No periodic forced password changes unless the password is known to be compromised.
  4. Allow all printable ASCII characters including emoji and spaces.
  5. Check passwords against breach dictionaries (haveibeenpwned's Pwned Passwords list, ~840M compromised passwords as of 2024) and reject matches.
  6. No composition hints ("your password must contain...") — they prime users to tack predictable sequences onto existing passwords.

These rules reflect ~15 years of breach-data analysis: complexity requirements produce predictable patterns (Password1!) that attackers' dictionaries now contain as entries. Length with no other constraint produces longer passwords from pure random with higher effective entropy.

Step-by-Step: Generate a Cryptographically Strong Password {#step-by-step}

For use in a password manager (the standard pattern in 2024):

  1. Open a client-side password generator (the mytoolslist one runs entirely in-browser).
  2. Set length to 20 characters (or your manager's suggested minimum, often 16–20).
  3. Use a 4-class pool — letters (both cases), digits, symbols.
  4. Generate the password using crypto.getRandomValues() (verified by viewing source or running dev-tools).
  5. Copy directly into the password manager entry for the target site.
  6. Optional: submit the generated password to haveibeenpwned's Pwned Passwords k-Anonymity API to confirm it doesn't appear in any known breach database.

The entire flow takes ~10 seconds and produces a ~131-bit password.

For memorized passwords (the password manager's master password is the canonical example):

  1. Generate a 4-word passphrase (Diceware-style).
  2. Pick a number or symbol insertion that breaks obvious dictionary patterns.
  3. Memorize by chunking — passphrase as one mental "picture" rather than four discrete words.
  4. Test by entropy estimation — 4 random words from 7,776-word Diceware list = ~51.7 bits (sufficient for a primary vault password).
  5. Optional: write down the first letter of each word with a delimiter, e.g., c-h-b-s → combine with memorization.

The passphrase > random-character-string preference for memorized passwords reflects human memory: random 20-character strings are unmemorable, but 4 random words are recoverable under stress.

Password Manager vs. Memorized: Two Different Categories {#manager-vs-memorized}

The two use cases have different optimal password strategies:

Stored in a manager (every site you log into):

  • Length 20+, full random, full character pool
  • Target ≥128 bits entropy
  • Don't even try to memorize — manager handles it
  • Each site has a unique password

Memorized (only the manager master password, ideally):

  • 4-word Diceware passphrase + 1 modifier
  • ~51–80 bits entropy (sufficient for a vault; the vault itself is the second line of defense)
  • Memorability matters more than entropy per character
  • Rotate every 5–10 years OR immediately if the manager service reports a breach

The 100+ "passwords" most humans juggle aren't really passwords anymore — they're vault entries. Memorizing them individually is a 2010-era pattern that no longer scales.

Pitfalls of Online Password Generators {#online-pitfalls}

Online password generators range from cryptographically sound to outright scam. Failure modes:

  1. Logging or transmitting to the server: generator shows password in UI but logs it server-side. Risk: server breach leaks all passwords users generated.
  2. Math.random() under the hood: reproducible PRNG allows an attacker who knows the seed to replicate the password. Math.random() is non-cryptographic; browser engines deliberately seed it from current time, which is guessable.
  3. Using current time as the seed: predictable outputs if the attacker knows the rough time of generation.
  4. Visual shuffling animations (a common UI pattern): the displayed final character is what gets copied, but the underlying random number was generated earlier in the animation timeline. This sometimes leaks the actual random state to the page-script-logger.
  5. Saving to URL hash #password=xyz to allow bookmarking — the URL becomes a permanent leak in browser histories and shared bookmarks.
  6. Analytics tracking that records the generated password (extremely rare but happens) — banner-ad-funded free tools are higher risk.

The defense: client-side-only generators that compute passwords in the browser and never transmit to a server. The mytoolslist password generator — and similar well-designed ones — use crypto.getRandomValues() and never call a server with the generated string.

Browser-Based Generation: crypto.getRandomValues() vs Math.random() {#crypto-vs-math}

The two most common browser APIs for randomness:

  • Math.random(): 64-bit floating-point in [0, 1). Seeded from JS engine's internal PRNG. Reproducible after observing 2+ outputs. Don't use for security.
  • crypto.getRandomValues(): pulls entropy from OS hardware noise (RDRAND instruction on modern x86, ARMv8 equivalent on ARM). Cryptographically secure per NIST SP 800-90A. Use for security.

Code example for a secure password generator in plain JavaScript, using rejection sampling to avoid the modulo bias that a naive n % pool.length introduces:

function secureRandomLowerUpperDigitSymbol(length) {
  // 84 printable chars: A–Z, a–z, 0–9, and a curated symbol set.
  const pool = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789!@#$%^&*()-_=+";
  const poolLen = pool.length; // 84
  // Reject any 32-bit random value ≥ maxValid so character probabilities stay uniform.
  // Without rejection, 84 doesn't divide 2³² evenly, so certain characters would
  // be ~1.5× more likely than others — a strict cryptographic defect.
  const maxValid = Math.floor(0xFFFFFFFF / poolLen) * poolLen;
  const out = new Uint32Array(length);
  let i = 0;
  // Overprovision the random buffer to reduce inner-loop iterations.
  while (i < length) {
    const buf = new Uint32Array(length * 2);
    crypto.getRandomValues(buf); // <-- the cryptographically secure line
    for (const n of buf) {
      if (i >= length) break;
      if (n < maxValid) out[i++] = n % poolLen;
    }
  }
  return Array.from(out, n => pool[n]).join('');
}

The rejection-sampling approach (per NIST SP 800-90A and RFC 4086 "Randomness Requirements for Security") keeps the character distribution uniform. Without it, sampling with n % 84 biases the lower 12 of the 84 character buckets.

The mytoolslist password generator and most reputable online generators use this exact pattern. To verify: open dev-tools, look at the page's network traffic during generation, confirm zero outgoing requests carrying the password string.

How Long Will Your Password Resist a Brute-Force Attack? {#brute-force}

Modern attacker capabilities (conservative estimates, 2024 hardware):

| Attacker Type | Guess Rate | 80-bit password | 128-bit password | |---|---|---|---| | Online service (rate-limited) | 100/sec | ~3.83 × 10¹⁴ years (384 trillion years) | heat death of universe | | Single GPU (consumer, RTX 4090-class) | 10⁹/sec | ~3.83 × 10⁷ years (38 million years) | ~3.4 × 10³⁰ years | | Single high-end GPU cluster (10⁴ GPUs) | 10¹²/sec | ~3.83 × 10⁴ years (38,300 years) | ~3.4 × 10²⁷ years | | State-level (NSA-class) | 10¹⁵/sec | ~38 years | ~3.4 × 10²⁴ years | | Hypothetical quantum computer (Grover) | 10²⁵/sec | ~0.4 seconds | ~10¹⁴ years (100 trillion years) |

The 128-bit target renders your password effectively secure against every attacker short of a state-level quantum computer — and quantum computers capable of breaking 128-bit AES (Grover's algorithm, ~2⁶⁴ operations) are decades from deployment and would themselves be the headline story of the era.

The takeaway: 20 random characters from a 95-symbol pool is essentially unbreakable. Even 16 characters is sufficient for practical purposes. Worry about reuse, not composition.

Related Tools

Frequently Asked Questions

How long should a strong password be in 2024?

Minimum 12 characters for low-value accounts, 16+ for high-value. NIST's 2024 Draft SP 800-63B Rev 4 explicitly removed the "12 chars max no benefit" cap that older Microsoft guidance imposed; longer is strictly better, with diminishing returns after ~20. A 20-character random password from a 95-symbol pool is ~131 bits — beyond practical attack.

What is the most secure online password generator?

A client-side-only generator that uses crypto.getRandomValues() and never transmits the generated string to a server. Reputable examples: 1Password's built-in generator, Bitwarden's, and the mytoolslist password generator. Verify in dev-tools that no network requests leave the page during generation.

Are password manager-generated passwords safer than manually chosen ones?

Yes, by a wide margin. Manager-generated passwords pull from the full 95-symbol pool with no human-pattern biases. Manually chosen passwords (e.g., "the_quick_brown_fox_jumps!") have at most ~80 bits even when long, because the chunking is predictable to dictionary attacks. Random 20-character strings have ~131 bits and are not in any dictionary.

Should I rotate passwords every 90 days?

NIST 2024 explicitly recommends against forced periodic rotation for uncompromised passwords. The practice causes users to produce incremental variants (Password2024! → Password2025!) that are more guessable than the original. Rotate immediately only when a service breach is disclosed. Note: this represents a recent reversal of prior NIST guidance — earlier versions of SP 800-63B did recommend periodic rotation, which is what created the Password2024! → Password2025! failure pattern that 2024's revised guidance explicitly retires.

What is a passphrase, and when should I use one?

A passphrase is a sequence of 4+ random words from a known word list (Diceware uses 7,776 English words). Each word adds ~12.92 bits; 4 words = ~51.7 bits, 6 words = ~77.5 bits. Use for the master password of your password manager — the one password you must memorize. For all other accounts, generate random 20-character strings and store them in the manager.

Do password complexity rules still matter?

NIST 2024 says no — not as a user-facing requirement. Modern guidance: any printable ASCII character is acceptable; length is the primary lever. Don't impose rules like "must include a symbol" on your users; they produce predictable patterns (P@ssw0rd!) and increase friction without meaningful entropy gain.

What is the difference between a password and a passkey?

A passkey is a public-key cryptographic credential (FIDO2 / WebAuthn standard). The site stores the public key; the user's device holds the private key in a hardware security module. The "password" is effectively just a biometric or device PIN that unlocks the private key. Passkeys eliminate password phishing entirely. Major platforms (Apple, Google, Microsoft, GitHub, PayPal) have rolled them out in 2023–2024; expect passkeys to replace passwords for high-value accounts over the next 5 years.

Are password generators safe to use if the site has ads?

Lower trust — banner-ad-funded generators pose a higher risk of analytics tracking logging generated passwords. The defense: use a tool (like the mytoolslist password generator) that runs client-side only, has no third-party ad network, and where you can verify in dev-tools that no network requests leave the page during generation. Client-side generation with crypto.getRandomValues() is the gold standard; everything else is a compromise.