Password Generator

A password generator creates random, hard-to-guess passwords based on selected length and character rules. A good generator relies on cryptographically secure randomness and combines uppercase letters, lowercase letters, numbers, and symbols only when the target system can actually accept them. Strong passwords reduce the risk of dictionary attacks, brute-force guessing, and credential stuffing, but they do not replace good security habits such as using a password manager, keeping every account unique, and enabling multi-factor authentication. Very complex passwords should not be memorized or reused; they should be stored securely. For shared systems, rotation, ownership, and access rules also need clear handling.

The password generator draws randomness from crypto.getRandomValues(new Uint32Array(n)), which fills a typed array with cryptographically secure pseudo-random values sourced from the operating system's entropy pool (getrandom on Linux, BCryptGenRandom on Windows, SecRandomCopyBytes on macOS/iOS). This is a CSPRNG as defined by the W3C Web Cryptography API — unlike Math.random(), which in V8 uses the xorshift128+ algorithm and is explicitly documented as non-cryptographic and predictable from a small sample of outputs. The character pool is assembled from user-selected character classes: uppercase (26 letters A-Z), lowercase (26 letters a-z), digits (10 characters 0-9), and symbols (32 characters from !@#$%^&*()_+-=[]{}|;:,.<>?), yielding a maximum pool of 94 characters. A custom character set or exclusion list (including an ambiguous-character filter that removes i, I, l, L, 1, o, O, 0) further refines the pool. Each password character is selected by taking array[i] % pool.length, which is uniformly distributed because the CSPRNG output is uniform over 32 bits and the modulo bias (|pool| does not divide 2^32 evenly) is negligible for pools under 256 characters — the bias is under 0.00000006%, far below any practical concern. Password strength is measured by the size of the search space: for a pool of size C and password length L, the number of possible passwords is C^L. The entropy in bits is log2(C^L) = L × log2(C). For a 16-character password with all four character classes enabled (C=94), this yields 94^16 ≈ 4.4 × 10^31 combinations, or about 105 bits of entropy. At a hypothetical attack rate of 10^12 guesses per second (roughly the throughput of a large GPU cluster against a fast hash like NTLM), exhaustive search would take approximately 4.4 × 10^19 seconds — far longer than the age of the universe. This model assumes the attacker must test every combination (no dictionary or pattern-based shortcuts) and that the password is hashed with a slow, salted algorithm like bcrypt or Argon2id rather than stored in plaintext. NIST SP 800-63B recommends a minimum of 8 characters for user-chosen passwords and at least 6 randomly generated characters for machine-generated credentials, with the character set documented. The generator's length range of 4–64 characters covers everything from PIN codes to high-entropy machine credentials. The start-with-letter option ensures the first character is drawn from [A-Za-z], which satisfies legacy systems that require passwords to begin with a letter.

• CSPRNG source: crypto.getRandomValues() pulls entropy from the OS kernel's CSPRNG (getrandom/BCryptGenRandom/SecRandomCopyBytes) — unlike Math.random() (xorshift128+), it is not predictable, not seedable by the page, and suitable for credential generation.
• Character space math: With all four classes enabled the pool size is 94; entropy per character is log2(94) ≈ 6.55 bits. A 16-character password carries ~105 bits of entropy; doubling the length to 32 raises this to ~210 bits.
• Modulo selection: array[i] % pool.length maps the 32-bit CSPRNG output to a character index — the bias is under 6 × 10^-8 % for pools under 256 characters, making it cryptographically irrelevant.
• Brute-force resistance model: At 10^12 guesses/second (GPU cluster scale), a 16-character, 94-symbol password would take ~10^19 seconds to exhaust — but this assumes a fast hash; bcrypt at cost factor 12 drops the attacker to ~10^4 guesses/second, making even 8-character passwords resilient.
• Ambiguous character exclusion: The filter removes {i, I, l, L, 1, o, O, 0} (8 characters) — this reduces the pool from 94 to 86, costing roughly 0.6 bits of entropy per character, which is acceptable for the usability gain in manual transcription scenarios.
• NIST SP 800-63B alignment: The standard requires a minimum of 6 randomly chosen characters for machine-generated secrets and recommends documenting the character space — the generator's presets (Simple 8-char, Strong 20-char) map to different assurance levels.
• localStorage history: The last 10 generated passwords are persisted in window.localStorage, which is scoped to origin and browser profile — clearing history removes them from storage, but a disk-level forensic tool could recover them because localStorage is stored as a plaintext SQLite database in the browser profile directory.