Weak passwords remain the single largest source of account compromise. Year after year, breach reports confirm the same pattern: credential stuffing, phishing, and reused passwords vastly outnumber sophisticated exploits. The good news is that the countermeasures are well understood, have evolved significantly in the last decade, and have been distilled by the National Institute of Standards and Technology (NIST) into a short set of guidelines anyone can follow. This guide explains the math behind password strength, summarizes the modern NIST position, and walks through the decisions our password generator makes on your behalf.
The Core Concept: Entropy
A password's strength is measured in bits of entropy — the base-2 logarithm of the total number of passwords that could have been generated under the same rules. If you draw 12 characters at random from a pool of 94 printable ASCII characters, the entropy is 12 × log₂(94) ≈ 78.6 bits. There are approximately 4 × 10²³ passwords in that search space. Even a well-funded attacker running GPUs at a trillion guesses per second takes millennia.
Entropy collapses quickly as the pool shrinks. A 12-character lowercase-only password has only 12 × log₂(26) ≈ 56.4 bits — about 10¹⁷ possibilities. That crosses into brute-force territory for a nation-state adversary. The single most effective upgrade you can make is not adding complexity rules to a short password but simply making it longer.
Why Length Beats Complexity
A common password policy requires at least one uppercase letter, one digit, and one symbol. From an entropy standpoint this expands the per-character pool from 26 to roughly 94 — a useful improvement. But the same gain is available for free by adding characters to the password: a 16-character lowercase password has 16 × log₂(26) ≈ 75 bits, roughly as strong as a 12-character 94-pool password. Users find four more lowercase characters much easier to memorize than meeting complexity requirements, and the resulting passwords tend to be stronger in practice.
NIST SP 800-63B formalizes this insight. The current guideline recommends minimum length (8 characters for user-chosen, 6 for randomly generated), prohibits composition rules, and abolishes periodic forced rotation. Complexity rules without length requirements push users toward predictable patterns (Password1!, Summer2024$) that attackers model explicitly.
Randomness: Why crypto.getRandomValues Matters
The raw bytes underneath any generated password come from a pseudorandom number generator (PRNG). Not all PRNGs are suitable for security. Math.random() in browsers and Node is a fast non-cryptographic PRNG designed for games and simulations; its internal state can be recovered after a few outputs. Using it for passwords would be catastrophic.
The browser exposes a cryptographically secure source via crypto.getRandomValues(), which is backed by the operating system's CSPRNG — /dev/urandom on Linux and BSD, BCryptGenRandom (or platform-equivalent CNG providers) on modern Windows, SecRandomCopyBytes on macOS. These sources are continuously seeded by hardware events and interrupts; their output is indistinguishable from true randomness for any computational adversary. Our generator uses crypto.getRandomValues() exclusively — Math.random() is not imported or referenced anywhere in the code path.
Human Entropy Mode: Belt and Suspenders
For users who want additional assurance — or who operate under threat models that distrust OS CSPRNGs — our tool offers an optional Human Entropy Mode. When enabled, mouse movements, keystrokes, and touch events each contribute a conservative number of bits to an entropy pool. Once the pool reaches 128 bits (tracked by the progress bar), the tool XOR-mixes it with 256 bits of crypto.getRandomValues() and SHA-256 hashes the result to produce a uniform seed. Subsequent bytes are produced by continued hashing.
Critically, the human contribution cannot weaken the output. XORing with a uniform 256-bit mask preserves uniformity regardless of the pool's quality; the SHA-256 round destroys any residual structure. For users whose threat model does not require it, the standard mode is cryptographically sufficient on every modern browser.
Avoiding Modulo Bias
A subtle implementation error can undermine even the best PRNG. If you pick a character by taking a random byte and computing byte % poolSize, the result is uniform only when 256 is divisible by poolSize. For a 94-character pool, 256 mod 94 = 68, meaning the first 68 characters are slightly more likely than the remaining 26. Over millions of generated passwords this bias becomes statistically detectable and makes dictionary attacks slightly more effective.
The fix is rejection sampling: compute the uniform range L = 256 − (256 mod 94) = 188, and discard any byte at or above L. The average number of bytes consumed per character rises slightly (roughly 256/188 ≈ 1.36×), but every character becomes exactly equally likely. Our generator applies rejection sampling for every character draw.
Ambiguous Characters and Usability
Visual ambiguity between 0 and O, 1 and l and I, causes transcription errors when passwords must be typed from a screen into another device — a common scenario for router configuration, IoT onboarding, and printed backup sheets. Our 'Exclude ambiguous' option removes 0OoIl1 from the pool. The entropy cost is tiny — less than half a bit per character on a 94-pool — but the usability gain is substantial for any workflow involving manual transcription.
The Right Length for Your Threat Model
Different accounts warrant different strengths. A forgettable forum login may be fine at 12 characters (≈ 79 bits against a 94-pool), protected by the site's own rate-limiting anyway. A financial account or email (which often controls password resets for everything else) deserves 20+ characters (≈ 131 bits). Your password manager's master password — the one secret you actually memorize — should aim for 128 bits and be drawn from at least four random words or 20+ characters; it is the root of trust for your entire digital identity.
Storage: Password Managers Are Non-Negotiable
No one can memorize a unique 20-character random password for every account. The answer, universally endorsed across security literature, is a password manager: Bitwarden, 1Password, KeePassXC, or the built-in managers in Chrome, Safari, and Firefox. Generate a strong unique password per account, store it, and let autofill handle the rest. This eliminates reuse (credential stuffing's primary attack vector), eliminates phishing susceptibility (the manager only autofills on the exact domain), and lets you maximize length without memorization burden.
Clipboard Hygiene
Copied passwords are vulnerable to any process with clipboard read access. On Android and iOS this is permissive; on desktop it is less so but still worth defending against. Our tool auto-clears the clipboard 60 seconds after a copy. In practice, paste the password into its destination immediately. If you are using a password manager, prefer autofill over copy-paste when available — the manager can inject the password directly into the form without routing through the clipboard.
Rotation: The Modern View
The old advice to rotate passwords every 90 days has been officially deprecated. NIST SP 800-63B section 5.1.1.2 reads: "Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically)." Forced rotation leads users to weaker patterns (Summer2024$ → Summer2025$) that attackers model explicitly. Rotation should be event-driven: after a known breach, a suspicion of compromise, or when leaving a shared-access scenario.
Breach Monitoring
Even a perfect password becomes useless if the site storing it is breached and its hash is cracked. Monitor haveibeenpwned.com and enable breach notifications in your password manager. When a breach affects you, rotate the specific credential — not your entire vault.
Using Our Generator
Open the Password Generator, set the length, toggle the character classes, and click Generate. The strength meter shows entropy in bits and a NIST-aligned label. For high-value accounts, use the Bulk mode to produce 10–20 candidates at once, pick the one you prefer, and store it in your password manager. All generation happens in your browser; nothing is sent over the network, nothing is logged, and session history clears on reload.
Common Password Anti-Patterns That Still Persist
Despite a decade of guidance, users and IT policies still fall into predictable traps. Pattern substitution (P@ssw0rd, Summ3r2024!) produces passwords that look complex to a compliance checker but are modeled explicitly by cracking dictionaries — they add roughly zero real entropy. Keyboard-walking patterns (qwerty123, asdfghjkl) appear in every breach corpus and are tried first in any dictionary attack. Name + year formats (JohnSmith1987) are trivially enumerated when basic social data is known. Reusing the service name (NetflixPassword1) satisfies a "different password per site" policy technically while providing none of its actual benefit: a credential-stuffing attacker will immediately try the pattern across other sites. The only reliable defense against these is random generation — no human-chosen password meets modern entropy requirements consistently.
Enterprise Password Policy: What Actually Works
If you set IT policy for a team, the single highest-impact change you can make is abandoning composition rules (requiring symbols, digits, mixed case) in favor of length minimums and breach-corpus blocklisting. NIST SP 800-63B explicitly recommends: require minimum length (12+ characters for user-chosen), disallow known-compromised passwords via a live blocklist (the Have I Been Pwned API provides this for free), eliminate periodic forced rotation, and never impose composition rules. Pair this with mandatory 2FA for all accounts and centralized password management (Bitwarden Business, 1Password Teams) so employees never need to memorize account passwords. These four changes typically eliminate 80–90% of credential-related incidents for mid-size teams, at a cost of a few hours of policy work and a per-user password-manager license.
The Role of Breach Monitoring Services
Have I Been Pwned (haveibeenpwned.com) maintains a database of over 12 billion compromised credentials from thousands of breaches. Two practical uses: (1) check any email address or password hash before trusting it for a new account, and (2) subscribe to domain-level notifications so you learn immediately when credentials on your email domain appear in a new breach. Enterprise alternatives like Spycloud, Have I Been Pwned for Enterprise, and the breach-alert features built into most password managers extend this with darkweb monitoring and real-time credential-exposure detection. For individual users the free HIBP email-notification service is sufficient. For IT teams protecting a workforce, the paid tier integrates with identity providers (Okta, Azure AD, Google Workspace) to force password resets automatically on detection.