Why Password Strength Actually Matters
Most breaches don't involve a clever hacker typing at a keyboard. They involve automated tools iterating billions of combinations per second against a stolen hash database. The math is stark: an 8-character lowercase password has 26^8 = 208 billion combinations — a modern GPU cracks that in under a minute. A 20-character mixed-character password has roughly 90^20 = 1.2 × 10^39 combinations — longer than the estimated remaining life of the sun to crack at the same speed.
Length is the single most important factor. Every additional character multiplies the keyspace by the alphabet size. Going from 16 to 20 characters is not 25% harder to crack — it's (90^20 / 90^16) ≈ 65 million times harder.
Entropy: the right metric
Security professionals measure password strength in bits of entropy. Entropy = log₂(alphabet_size) × password_length. Each bit of entropy doubles the number of possible passwords an attacker must try. The industry threshold for "practically uncrackable" is 80+ bits. This tool shows entropy in real time as you adjust settings so you can see the tradeoff directly.
| Length | Alphabet | Entropy | Verdict |
|---|---|---|---|
| 8 | lowercase only (26) | 37 bits | Weak — cracked in seconds |
| 10 | alphanumeric (62) | 59 bits | Fair — days on a GPU farm |
| 14 | full charset (90+) | 91 bits | Good — centuries to crack |
| 20 | full charset (90+) | 131 bits | Strong — computationally infeasible |
How This Generator Works
Most online generators use Math.random(), which is a pseudorandom number generator seeded by the system clock — predictable enough that security researchers have cracked it. This tool uses the Web Crypto API (crypto.getRandomValues()), a CSPRNG built into every modern browser and backed by OS-level entropy sources (hardware events, CPU randomness instructions).
Rejection sampling — eliminating modulo bias
A subtle bug in many generators: if your alphabet has N characters and you reduce a random byte (0–255) by taking byte % N, the remainder distribution is not uniform unless 256 is divisible by N. For example, with a 95-character full alphabet, bytes 0–5 map to characters with slightly higher probability than bytes 6–94. Over millions of generated passwords, this skews character frequency.
Our generator uses rejection sampling: if a byte falls in the "biased range" (≥ ⌊256/N⌋ × N), we discard it and try the next byte. This guarantees a perfectly uniform distribution — every character has exactly equal probability of appearing at every position.
API Keys: the Format Conventions
Modern SaaS products use prefixed API keys for good reasons. Stripe uses sk_live_ for live secret keys and pk_test_ for publishable test keys. GitHub uses ghp_ for personal access tokens. These prefixes serve three purposes:
- Secret scanning: GitHub, GitLab, and cloud providers scan for leaked credentials in commits. Prefixes let them identify and revoke keys automatically. If you push a file with
sk_live_in it, GitHub's secret scanning alerts your account immediately. - Type safety: In code, prefixes prevent test keys from being used against production endpoints and vice versa.
- Rotations: When you rotate keys, the prefix stays the same while the random body changes. Your audit logs stay readable.
Prefix conventions by type
| Use case | Prefix convention | Example |
|---|---|---|
| Live secret key | sk_live_ | sk_live_xK9mR2pL… |
| Test secret key | sk_test_ | sk_test_4nFv8qWj… |
| Publishable/public key | pk_live_ | pk_live_aB3c7dEf… |
| Webhook signing secret | whsec_ | whsec_9pLm2xRq… |
| Internal service token | svc_ | svc_k3Nm9pWx… |
| Personal access token | pat_ | pat_vQ8rL1mN… |
Best Practices for Secret Management
Rotate secrets on schedule, not just on breach
A compromised key may be used silently for weeks before detection. Rotation schedules limit the damage window. For production API keys: rotate every 90 days minimum. For service account tokens: rotate every 30 days. For webhook secrets: rotate when changing vendors or after any team departure.
Store in environment variables, never in code
The most common credential leak is a hardcoded secret committed to a Git repository. Use environment variables (.env files locally, encrypted secrets in CI/CD). Services like Cloudflare Workers and Vercel have built-in encrypted secret stores — use them instead of checking credentials into your repo.
Scope keys to least privilege
Never generate a single "master" API key that can do everything. Create one key per service, scoped to the minimum permissions it needs. When you rotate or revoke a key, only that service is affected — not your entire integration stack.
Password Managers: the Right Solution for Humans
The fundamental problem with strong passwords is memorability — a 20-character random string is not something a human should memorize. The answer is not simpler passwords; it is a password manager. Bitwarden (open source, free tier), 1Password, and Dashlane all generate, store, and autofill strong passwords. You memorize one master password and let the manager handle the rest.
Generate a different strong password for every site. Reused passwords are the #1 cause of account takeovers: attackers buy breached credential lists, then automatically test them across hundreds of services ("credential stuffing"). A unique password per site makes a breach of one site harmless to all others.