Introduction
Passwords remain a common authentication factor for websites, infrastructure, encrypted archives and service accounts. Human-created passwords tend to follow patterns that attackers prioritize, while arbitrary complexity rules often produce predictable substitutions.
A password generator samples characters from a defined pool using a secure random source. The utily.tools Password Generator controls length, character sets, ambiguous characters and quantity so users can produce independent values appropriate for different systems.
Search space and entropy
If every character is selected independently and uniformly from a pool of N symbols, a password of length L has N^L possibilities and theoretical entropy of L × log2(N) bits. Length usually increases the search space more effectively and memorably than stacking arbitrary composition rules.
The formula only applies when generation is truly uniform. Human choices, biased modulo operations and predictable pseudo-random generators reduce effective entropy. Password security also depends on rate limits, storage, reuse and resistance to phishing.
Technical foundations and behavior
Browsers provide crypto.getRandomValues for cryptographically strong random bytes. Mapping a byte directly with byte % pool.length can introduce modulo bias when 256 is not divisible by the pool size. Rejection sampling avoids that bias.
Uniform sampling
Calculate the largest multiple of the pool length below 256 and discard bytes at or above that limit. Accepted bytes map evenly to pool positions. For normal password sizes the performance cost is negligible.
Composition requirements
If a target requires at least one uppercase, lowercase, number and symbol, generate one character from each required pool, fill the rest from the combined pool and securely shuffle. Testing after generation and retrying is also possible but less deterministic.
Storage and use
Users should store unique generated passwords in a password manager. Servers should hash passwords with a salted, memory-hard function such as Argon2id. Generated API secrets may need greater length and controlled rotation rather than human typing convenience.
Real-world applications
Password-manager credentials
A unique 20-character value protects one account and can be rotated without influencing credentials for other services.
Temporary test users
QA automation creates independent credentials without embedding a shared memorable password in source code.
Service bootstrap secrets
Infrastructure provisioning creates a long initial secret, stores it in a vault and rotates or replaces it with short-lived identity.
Standards and deeper technical reference
Entropy, search space and unbiased selection
If each of L positions is selected independently and uniformly from an alphabet of N symbols, the theoretical entropy is L × log2(N) bits and the search space is N^L. This formula does not describe a human-chosen password, whose choices are patterned and must be evaluated against attacker dictionaries.
A generator needs a cryptographically secure random source such as crypto.getRandomValues. Mapping a random byte with byte % N is biased unless N divides 256. Rejection sampling discards values outside the largest multiple of N below the source range before applying modulo.
| Alphabet | Symbols | 12 characters | 20 characters |
|---|---|---|---|
| Lowercase letters | 26 | 56 bits | 94 bits |
| Upper + lower + digits | 62 | 71 bits | 119 bits |
| 94 printable ASCII symbols | 94 | 79 bits | 131 bits |
| Six-word list of 7,776 words | 7,776 per word | About 77 bits for six words | Not applicable |
Current NIST guidance for password verifiers
NIST SP 800-63B-4 requires at least 15 characters for a password used as a single authentication factor and at least eight when it is part of multi-factor authentication. Verifiers should allow at least 64 characters, accept spaces and Unicode, reject commonly used or compromised values, and must not impose character-class composition rules or periodic changes without evidence of compromise.
These verifier rules and generated-secret design solve different problems. A generated 20-character secret can have excellent entropy, while a user-selected 15-character phrase still needs breach-list screening and rate limiting. Passwords are not phishing-resistant, so stronger assurance uses phishing-resistant multifactor authentication.
Storage and operational security
Servers store a per-password salt and the output of a memory-hard or approved password hashing scheme with its cost parameters. Salts need uniqueness, not secrecy. A server-side pepper can add defense in depth when stored separately, but it creates rotation and availability obligations.
Generate a unique password for every account and store it in a password manager. Clipboard history, screenshots, logs and analytics can leak even a locally generated value. Clear temporary UI state where practical and never transmit generated passwords merely to measure strength.
Primary specifications and references
Conclusion
Secure password generation is a probability problem supported by cryptographic randomness. Length, uniform selection and uniqueness matter more than visual complexity alone.
My preference is long generated credentials stored in a password manager, combined with multi-factor authentication and modern server-side hashing. Use the utily.tools Password Generator for appropriate test or personal values, and read the site security articles for authentication concepts beyond passwords.