Secure Password Generator: Entropy, CSPRNG, and Best Practices

The Difference Between Random and Cryptographically Secure Random

Most developers know Math.random(). It's fast, convenient, and utterly unsuitable for security purposes. Math.random() is a Pseudo-Random Number Generator (PRNG) — it produces a sequence of numbers that looks random but is deterministic. Given the seed and the algorithm, every future value is predictable.

For passwords, API keys, session tokens, and cryptographic secrets, you need a Cryptographically Secure PRNG (CSPRNG). A CSPRNG gathers entropy from unpredictable hardware sources — CPU timing jitter, I/O events, interrupt timing — and uses them to seed a cryptographically strong algorithm. The output is computationally indistinguishable from true randomness.

In browsers, this is exposed via the Web Crypto API:

// Insecure — PRNG, predictable with enough compute
Math.random(); // → 0.7363206754...

// Secure — CSPRNG, hardware entropy
const array = new Uint8Array(32);
crypto.getRandomValues(array); // → [43, 217, 8, 156, ...]

Our Password Generator uses crypto.getRandomValues() exclusively. Every character in every password is selected using hardware entropy, making the output suitable for database credentials, API keys, encryption passphrases, and production secrets.

Understanding Password Entropy

Entropy measures the unpredictability of a password in bits. More bits = more guesses required for brute force. The formula:

entropy = log2(charset_size ^ length)
        = length × log2(charset_size)

Practical entropy values for common configurations:

A modern GPU cluster can test roughly 10¹² passwords per second against a bcrypt hash. At that rate:

• 52 bits → cracked in seconds
• 80 bits → cracked in years
• 100+ bits → computationally infeasible with current technology

For any credential that protects production infrastructure, aim for 100+ bits of entropy. That means 16+ characters with full character set, or 20+ characters alphanumeric. For master keys, encryption passphrases, or root credentials, use 32+ characters.

NIST Password Guidelines (SP 800-63B)

The National Institute of Standards and Technology updated its password guidance in 2017 and again in 2024. The current recommendations differ significantly from older "complexity" rules:

What NIST now recommends:

• Minimum 8 characters for user-created passwords
• Minimum 6 characters for machine-generated passwords
• Maximum length of at least 64 characters (don't impose short maximums)
• Allow all printable ASCII characters plus spaces
• Remove mandatory complexity rules (uppercase + lowercase + number + symbol requirements)
• Check passwords against known-compromised lists (HaveIBeenPwned API)
• Do not require periodic password rotation unless compromise is suspected

What NIST discourages:

• Password hints or knowledge-based authentication
• SMS-based 2FA (deprecated — use TOTP or hardware keys)
• Complexity requirements that lead to predictable patterns like Password1!

The rationale: forced complexity rules produce passwords like P@ssw0rd! which score high on complexity metrics but appear in every breach database. Length and true randomness are more effective than complexity theater.

For machine-generated credentials (API keys, database passwords, service account secrets), use our generator at 24+ characters with full character set — this satisfies any policy and is impossible to remember (which is fine, since it goes in a secrets manager, not memory).

Character Set Selection Guide

For environment variables and config files, avoid characters that need shell escaping: $, `, \, ", '. A 24-character alphanumeric password avoids all of these while still providing 143 bits of entropy.

For bcrypt-hashed database passwords, the 72-character truncation limit means passwords beyond 72 bytes provide no additional security. Stay within 64 characters for bcrypt-stored passwords and use Argon2id for new systems.

For HS256 JWT secrets, NIST SP 800-107 recommends at least 256 bits (32 bytes) of entropy for HMAC-SHA256. Use our generator with 32+ characters and full character set, then encode as hex or Base64 for use in your auth configuration. See our JWT Debugger to verify the algorithm your tokens are using.

Why Local Generation Is Non-Negotiable

Generating a password on a remote server — even over HTTPS — introduces risk:

1. Server logs: The password may appear in request/response logs before it reaches you
2. TLS interception: Corporate proxies, CDN providers, or network equipment may terminate TLS and inspect traffic
3. Server compromise: A compromised password generator service has harvested thousands of credentials before anyone noticed
4. Vendor trust: You have no visibility into what a third-party service does with generated values

Our generator produces every character using your CPU and the browser's hardware entropy pool. The password never exists outside your browser tab. This "zero-trust" architecture means the security model is simple: if your machine isn't compromised, your generated passwords aren't compromised.

Hashing Before Storage

Generated passwords should never be stored in plaintext. When building systems that store user passwords, always hash with a slow, salted algorithm:

Use our Hash Generator to test hash outputs and understand the difference between raw SHA hashes and proper password hashing. For API secrets and tokens (not user passwords), a raw SHA-256 HMAC is appropriate — it's only user passwords that need slow hashing.

Passphrase Alternative: Diceware

For passwords humans need to type or remember (master password managers, disk encryption), random word passphrases (Diceware) can be more usable while remaining secure:

• 4 words from a 7,776-word wordlist: 51.7 bits of entropy
• 5 words: 64.6 bits
• 6 words: 77.5 bits — equivalent to a random 13-character alphanumeric password
• 7 words: 90.5 bits — considered very strong

correct-horse-battery-staple-7 is 30 bits stronger than P@ssw0rd1 and far easier to remember. The security comes from the random selection process, not the apparent complexity.

DevOps Workflow: Managing Secrets

For infrastructure and application secrets, the workflow is:

1. Generate a high-entropy secret with our password generator (24-32 characters, full charset)
2. Store in a secrets manager: AWS Secrets Manager, HashiCorp Vault, Azure Key Vault, or 1Password Secrets Automation — never in .env files committed to version control
3. Inject at runtime via environment variables or mounted secrets volumes
4. Rotate on a schedule (quarterly for service accounts, immediately on compromise suspicion)
5. Audit access logs to detect unexpected secret retrieval

For documenting your team's secrets management policy, use our Markdown Editor to write a runbook. Include rotation schedules, emergency revocation procedures, and onboarding steps so the policy survives team turnover.

Naming Conventions for Generated Keys

When you generate secrets for multiple services, consistent naming helps. Use our Case Converter to format secret names consistently:

STRIPE_SECRET_KEY=sk_live_...
DATABASE_PASSWORD=...
JWT_SIGNING_SECRET=...
AWS_ACCESS_KEY_ID=...

SCREAMING_SNAKE_CASE is the standard for environment variables across all major platforms. Keep names descriptive enough that their purpose is clear without revealing what they protect.