Password Generator: Create Strong Random Passwords Online

The Complexity Myth: Why “P@ssw0rd1!” Is Weaker Than You Think

For over a decade, IT security policy was shaped by a 2003 NIST document that pushed mandatory complexity requirements: uppercase letters, numbers, special characters, forced rotations. The author of that guidance, Bill Burr, publicly apologized in 2017. The rules he wrote made passwords harder for humans but barely harder for computers.

Here is why: attackers do not brute-force character-by-character. They use rule-based attacks in tools like Hashcat that know “users capitalize the first letter, append a number, and substitute @ for a”. A password matching those patterns -- even with all complexity boxes checked -- has far less effective entropy than it appears. The updated NIST Special Publication 800-63B (2017, revised 2024) explicitly removed complexity requirements and instead mandates checking new passwords against lists of known-compromised credentials.

The correct mental model is this: what matters is the size of the search space an attacker must cover, which is determined by the true randomness of your password and its length. A random 16-character password from a 95-character alphabet (all printable ASCII) provides log2(95^16) ≈ 105 bits of entropy. At 10 billion guesses per second -- the throughput of a high-end GPU cluster in offline attack mode -- exhausting that space would take longer than the current age of the universe.

The Password Problem in Numbers

The scale of poor password hygiene is hard to overstate. According to a 2026 analysis of 19 billion leaked credentials published by Spacelift, only 6% of passwords in that dataset were unique -- meaning 94% were reused or commonly used passwords. Only 27% of US adults use a random password generator to create new passwords, per research aggregated by Huntress (2026). The rest mix words with numbers in patterns attackers know by heart.

The consequences show up in breach data. According to the Verizon 2025 Data Breach Investigations Report, 37% of successful web application attacks used brute force -- up from 21% the year before. Per Heimdal Security's 2026 breach analysis, 61% of all breaches involved compromised credentials. These are not sophisticated supply-chain attacks; they are the direct result of weak, reused, or guessable passwords at scale.

How a Secure Password Generator Actually Works

The critical distinction between a secure and an insecure password generator is the randomness source. Most languages have two categories of random number generators: general-purpose PRNGs (pseudorandom number generators) and CSPRNGs (cryptographically secure PRNGs). Only CSPRNGs are appropriate for security-sensitive work.

Why Math.random() Is Never Acceptable

JavaScript's Math.random() is explicitly documented as unsuitable for security purposes. V8's implementation uses xorshift128+ with a 128-bit state -- fast and uniform, but the internal state is recoverable. With enough observed outputs, an attacker can predict future values. Browsers expose this function because it is fast and adequate for games, animations, and simulations. It is not for passwords.

The correct browser API is crypto.getRandomValues(), part of the Web Crypto API (W3C specification). It reads from the OS kernel's CSPRNG, which in turn is seeded from hardware entropy sources (interrupt timing, disk I/O jitter, hardware RNG instructions like Intel's RDRAND).

// WRONG -- never use for passwords
const bad = Math.random().toString(36).slice(2);

// CORRECT -- Web Crypto API (browser + Node.js 19+)
function generatePassword(length = 16, charset = '') {
  const lower = 'abcdefghijklmnopqrstuvwxyz';
  const upper = 'ABCDEFGHIJKLMNOPQRSTUVWXYZ';
  const digits = '0123456789';
  const symbols = '!@#$%^&*()-_=+[]{}|;:,.<>?';
  charset = charset || lower + upper + digits + symbols;

  const array = new Uint32Array(length);
  crypto.getRandomValues(array);

  // Rejection sampling to avoid modulo bias
  const charsetLen = charset.length;
  const maxUnbiased = Math.floor(0x100000000 / charsetLen) * charsetLen;

  let result = '';
  let i = 0;
  while (result.length < length) {
    const val = array[i++ % array.length];
    if (val < maxUnbiased) {
      result += charset[val % charsetLen];
    }
    if (i >= array.length) {
      crypto.getRandomValues(array);
      i = 0;
    }
  }
  return result;
}

// Example usage
generatePassword(20);
// => 'kT#9xZ!2mQr@vL$8nWpY'

Rejection Sampling: Eliminating Modulo Bias

A subtle but important detail: if you naively do randomByte % charsetLength, you introduce modulo bias when the charset length does not evenly divide the range of random values. For example, if your charset has 95 characters and your random value is a byte (0-255), the values 0-94 will appear more frequently than they should because 256 is not evenly divisible by 95. The fix -- rejection sampling -- discards values in the remainder range and draws again. The code above applies this correctly.

Server-Side Generation in Multiple Languages

// Node.js (crypto module)
const crypto = require('crypto');
const charset = 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!@#$%^&*';
const length = 20;
let password = '';
while (password.length < length) {
  const byte = crypto.randomBytes(1)[0];
  if (byte < Math.floor(256 / charset.length) * charset.length) {
    password += charset[byte % charset.length];
  }
}

// Python -- 'secrets' module (stdlib since 3.6)
import secrets
import string
alphabet = string.ascii_letters + string.digits + string.punctuation
password = ''.join(secrets.choice(alphabet) for _ in range(20))
# secrets.choice() uses os.urandom() internally -- CSPRNG

# Go
import (
    "crypto/rand"
    "math/big"
)
func generatePassword(length int, charset string) string {
    result := make([]byte, length)
    for i := range result {
        n, _ := rand.Int(rand.Reader, big.NewInt(int64(len(charset))))
        result[i] = charset[n.Int64()]
    }
    return string(result)
}

# Bash (useful for quick scripts)
< /dev/urandom tr -dc 'A-Za-z0-9!@#$%^&*' | head -c 20

Password Entropy: The Math Behind “Strong”

Entropy is the correct way to quantify password strength because it measures the size of the search space an attacker must explore. The formula is simple: entropy = log2(charset_size ^ length).

Note that these crack times assume the attacker has the hash and is running offline -- the worst-case scenario. Online attacks (guessing against a live login form) are throttled to thousands of attempts per second at most, making even a 50-bit password effectively uncrackable online. The offline scenario matters when a database is breached and attackers crack hashes locally.

The key takeaway: 80 bits of entropy is the informal modern threshold for high-security offline resistance. A 16-character password from a full printable ASCII charset (105 bits) or a 6-word Diceware passphrase (77.5 bits) both exceed this bar. An 8-character password -- even with symbols -- does not.

NIST SP 800-63B: What the Standard Actually Says

NIST Special Publication 800-63B is the US government's authoritative guidance on digital identity and authentication. The 2017 revision (with subsequent updates through 2024) made several landmark changes that contradicted a decade of conventional IT policy:

• No mandatory complexity rules. Organizations “SHALL NOT” require specific character types (uppercase, digits, symbols) unless the user chooses to include them.
• No periodic rotation without cause. Forced password changes every 90 days actually reduce security -- users predictably change Password1 to Password2. Rotation is only required when a compromise is suspected.
• Minimum length of 8 characters for memorized secrets, with a maximum of at least 64 characters to allow passphrases.
• Blocklist checking. New passwords must be checked against lists of commonly used, expected, or compromised values (NIST provides guidance; Have I Been Pwned's API is a practical implementation).
• Allow all printable Unicode and spaces. Restricting character sets reduces the effective entropy of user-chosen passwords.

CISA, the Cybersecurity and Infrastructure Security Agency, goes further in its 2025 guidance: it recommends passwords of 16 or more characters for regular accounts and 20+ characters for privileged accounts like admin or root. For developer tooling (API keys, service accounts), use generated secrets of at least 256 bits.

Passphrases vs. Random Character Passwords

Both approaches are valid when implemented correctly. The choice depends on how the password will be used:

Diceware Passphrases

Diceware generates passphrases by selecting words randomly from a 7,776-word list (6^5 = 7,776, one word per 5 dice rolls). Each word adds log2(7,776) ≈ 12.9 bits of entropy. A 6-word passphrase reaches 77.5 bits -- comparable to a 12-character random ASCII password, but far more memorable and easier to type. The EFF publishes an updated Diceware wordlist optimized for memorability.

// Diceware-style passphrase generator (Node.js)
const crypto = require('crypto');

// EFF large wordlist has 7776 words (indices 11111-66666 in base-6)
// For simplicity, this demonstrates the selection logic
function generatePassphrase(wordList, wordCount = 6) {
  const words = [];
  for (let i = 0; i < wordCount; i++) {
    const n = crypto.randomInt(wordList.length);  // Node.js 14.10+
    words.push(wordList[n]);
  }
  return words.join('-');
}

// Entropy = wordCount * log2(wordListSize)
// 6 words * log2(7776) = 6 * 12.925 = 77.55 bits
// Example output: "correct-horse-battery-staple-purple-fox"

When to Use Which

Password Managers: The Only Scalable Solution

Generating a unique strong password for every account is only sustainable with a password manager. A human cannot memorize hundreds of unique 20-character passwords. The standard security advice -- use a unique password per site -- is physically impossible without tooling.

Password managers generate and store passwords encrypted with AES-256-GCM, using a key derived from your master password via Argon2id or PBKDF2. The master password never leaves your device. Per OWASP's 2025 Password Storage Cheat Sheet, the recommended PBKDF2 iteration count for SHA-256 is 600,000 minimum. Even if the password manager's servers are breached, the attacker gets only ciphertext.

Major options include Bitwarden (open source, audited), 1Password (closed source, widely audited), KeePassXC (local-only, no sync), and Dashlane. For teams and CI/CD pipelines, HashiCorp Vault, AWS Secrets Manager, or GitHub Actions Encrypted Secrets are appropriate. Per the Stack Overflow Developer Survey 2024, 68% of professional developers reported using a password manager or secrets management tool.

Common Password Generation Mistakes (and How to Avoid Them)

1. Using a Weak Randomness Source

This is the most critical error. Any generator not using a CSPRNG (crypto.getRandomValues() in browsers, secrets module in Python, crypto/rand in Go) is producing passwords that could be predicted by an attacker who has observed enough of the generator's output. The hash generator tool and other cryptographic utilities on this site use the Web Crypto API exclusively.

2. Generating Passwords Server-Side and Transmitting Them

If a password generator makes an HTTPS request to a server to obtain the password, your password is exposed to the server's logs, TLS inspection middleware, and any infrastructure between you and the server. The gold standard is client-side generation -- the password is created in your browser's JavaScript context and never transmitted. You can verify this by opening DevTools, going to the Network tab, and confirming no requests are made when the password is generated.

3. Restricting Charset Too Aggressively

Some services reject passwords containing certain symbols. If your generator excludes symbols entirely to ensure compatibility, a 16-character alphanumeric-only password has log2(62^16) = 95.3 bits -- still excellent. The issue is generators that produce passwords that are too short AND symbol-free. Avoid generators that default to 8 characters with letters-only.

4. Not Verifying Against Breach Lists

While a truly random 16-character password has negligible chance of appearing in a breach database, it is good practice to verify new passwords against the Have I Been Pwned Passwords API (k-anonymity model -- only the first 5 hex characters of the SHA-1 hash are sent). This protects against edge cases and validates your randomness source. The NIST 800-63B standard mandates this check for verifiers.

The Future: Passkeys and Passwordless Auth

The FIDO2/WebAuthn standard, which underlies passkeys, replaces the password with a public-key credential stored on your device. When you authenticate, the device signs a challenge with the private key -- no secret is ever transmitted to the server. Bitwarden reported a 550% increase in daily passkey creation in Q4 2024 as Apple, Google, and Microsoft all shipped passkey support across their platforms.

Passkeys eliminate the password problem entirely for supported services. But as of 2026, hundreds of thousands of services still require passwords, and the transition will take years. Until then, generating unique, random, long passwords for every account -- stored in a password manager -- remains the correct approach. You can use our Password Generator tool to create cryptographically random passwords in your browser with zero server contact. For generating UUIDs as API tokens or session identifiers, see our UUID Generator.

Frequently Asked Questions

How long should a randomly generated password be?

NIST SP 800-63B sets a minimum of 8 characters but strongly encourages longer passwords. CISA recommends at least 16 characters for general accounts. For high-value targets -- password manager master passwords, SSH key passphrases, root accounts -- use 20+ characters or a 6-word Diceware passphrase (~85 bits of entropy). Length matters far more than complexity.

What makes a password generator truly random?

A secure generator must use a cryptographically secure pseudorandom number generator (CSPRNG) -- not Math.random() in JavaScript or random.random() in Python. In browsers, the Web Crypto API's crypto.getRandomValues() is the correct source. In Node.js, use crypto.randomBytes(). In Python, use secrets.token_urlsafe(). These pull entropy from the OS kernel's entropy pool, seeded from hardware events.

Is it safe to generate passwords online?

Yes, if the generator runs entirely client-side. A browser-based generator using crypto.getRandomValues() never transmits your password. Verify this by checking the Network tab in DevTools -- no requests should be made during generation. Avoid generators that clearly make server requests to produce results.

What is password entropy and why does it matter?

Entropy (measured in bits) quantifies how unpredictable a password is. The formula is log2(charset_size ^ length). A 16-character password using all printable ASCII (~95 chars) has ~105 bits of entropy. At 10 billion guesses per second -- a high-end GPU cluster -- exhausting 105 bits would take longer than the age of the universe. 80 bits is the modern threshold for high-security offline resistance.

Should I use a passphrase instead of a random character password?

Both are secure when done right. A 5-word Diceware passphrase offers ~64 bits of entropy; 6 words gives ~85 bits. Passphrases are better for things you type by hand (master passwords, SSH passphrases). Random character passwords are better when autofilled, as they provide maximum entropy per character for a given length.

Why do complexity rules backfire?

NIST SP 800-63B explicitly dropped mandatory complexity requirements because they produce predictable patterns (P@ssw0rd1!) that attackers model. Rule-based attacks in Hashcat exploit the fact that users substitute @ for a, capitalize first letters, and append numbers. NIST now mandates blocklist checking against compromised credentials instead of enforcing complexity rules.

How do password managers store passwords securely?

Password managers encrypt vaults using AES-256-GCM with a key derived from your master password via Argon2id (PBKDF2 in older implementations). The master password never leaves your device -- only the encrypted vault syncs. OWASP's 2025 guidance recommends a minimum of 600,000 PBKDF2-SHA256 iterations for key derivation. Even in a server breach, attackers get only ciphertext.

Related Articles