The Complete Password Security Guide: How to Generate and Manage Truly Strong Passwords

Your Password May Be More Fragile Than You Think

Almost every month a major site leaks user data. After a leak, the danger isn't "my password was seen" but that most people use one password everywhere—credentials leaked from site A get tried on B and C, and nine times out of ten they log in directly.

Another group goes to the opposite extreme, treating P@ssw0rd1! as "complex enough." That's self-deception. In the years we've built the password tools, we keep stressing one thing: a password's strength isn't how complex you feel it is, but how hard it actually is to compute.

Per leak databases like Have I Been Pwned, the weak passwords showing up in credential-stuffing dictionaries are just a few hundred variants. password, 123456, qwerty, P@ssw0rd make up a staggering share of real leaks. What you think is "creative" is already public script to an attacker.

How Attackers Break Your Password

Credential Stuffing: buy/leak account credentials from elsewhere, auto-try them across sites. This is why "one password everywhere" is fatal—one leak and all accounts are exposed.
Brute force / dictionary attack: short passwords and common word combos are exhausted in seconds to minutes on a consumer GPU. One GPU tries billions of hashes per second.
Social engineering & personal info: birthdays, names, pets, license plates. With a little knowledge of you (or your social profiles), attackers prioritize these in the dictionary.
Rainbow table: pre-compute a "common password → hash" lookup; with a leaked hash database, reverse directly. Salting defeats it.

Notice the common premise of all four: your password is either too common, too short, or tied to your info. Avoid those three and the cracking cost becomes too high for anyone to bother.

What "Strong" Actually Means

Three criteria, in priority order:

Long enough: start at 12–16 characters. Length raises cracking cost exponentially—far more than any "add a symbol."
Truly random: characters from a cryptographic RNG, not made up in your head. Human passwords have obvious patterns (capital first letter, trailing digit), low entropy.
Unique: different per site. This alone blocks credential stuffing.

Cracking time by password (offline brute force, intuition only; actual depends on attacker compute):

Password	Approx cracking cost
`password123`	Instant
`P@ssw0rd1!`	Seconds under dictionary attack
8-char random alphanumerics	Hours to days
12-char random alphanumerics+symbols	Thousands of years+
4 random-word passphrase	Also thousands of years

Entropy: A Quantifiable Standard for "Strength"

Cryptography measures randomness in entropy (bits). Rough formula: entropy ≈ log2(character set size) × length.

Lowercase (26): ~4.7 bits/char
- digits (36): ~5.17 bits/char
Upper+lower+digits+symbols (~95): ~6.57 bits/char

So:

Password	Estimated entropy
8-char complex	~52 bit
12-char complex	~79 bit
4 random common words (~11bit each)	~44–55 bit
5 random common words	~55–65 bit

Rule of thumb: ≥60 bit is "strong," ≥80 bit is "very strong." That's why a passphrase with enough truly-random words holds up like gibberish.

How to Generate: Leave It to Tools, Not Your Brain

Your own passwords, however "random," carry habits. Let a tool use a cryptographic RNG:

Random password / Token generator: configurable length and charset (upper/lower/digits/symbols), backed by crypto randomness, not pseudo-random.
After generating, run it through password strength analysis to confirm it isn't misjudged as weak by common rules.

Push length to 16+ directly. One more character multiplies cracking cost dozens of times. Right vs wrong ways:

// ❌ Wrong: Math.random is pseudo-random, predictable—don't use for passwords
const weak = Math.random().toString(36).slice(2, 10);

// ✅ Right: Web Crypto cryptographic randomness
function genPassword(len = 16) {
  const chars = 'ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz23456789';
  const arr = new Uint32Array(len);
  crypto.getRandomValues(arr);
  return Array.from(arr, n => chars[n % chars.length]).join('');
}

Passphrases: Memorable and Tough

If gibberish is hard to remember, try a passphrase (Diceware): pick 4–5 unrelated random words, join with separators, e.g. correct-horse-battery-staple (the classic example).

It's easier to remember than equal-length gibberish, yet entropy is just as high: each common word contributes ~10–13 bits, five words = 50–65 bits, far above most short random passwords. For handwritten/memorized use, it's the most practical scheme.

Don't use quotes, lyrics, or "first letters of a sentence"—that's still a predictable pattern. Words must be truly randomly chosen (use the tool's random-word feature, don't pick your own).

Advanced: add random digits and symbols between words, e.g. correct-7-horse-battery-3-staple—entropy steps up, still easy to remember.

Management: Manager + Unique + 2FA

Generating a strong password is only step one; if you can't remember it, it's useless.

Use a password manager (Bitwarden, 1Password, KeePass): store one unique strong password per site; you only guard one master password. Make the master a passphrase. Good managers are zero-knowledge—your vault is encrypted locally; the provider can't see plaintext either.
Turn on 2FA: even if the password leaks, a second dynamic code blocks login. The TOTP tool generates step-by-step codes, more reliable than SMS.
Don't rely on SMS alone for important accounts: SIM-swap attacks hijack SMS; prefer TOTP or hardware keys (Passkey) where available.

2FA reliability ranking:

Method	Security	Note
Hardware key / Passkey (WebAuthn)	Highest	Phishing-proof, nothing to steal
TOTP authenticator app	High	No SMS dependency, recommended
SMS	Low	SIM-swap vulnerable
Email code	Medium-low	If email leaks, cascade fails

Developer View: How to Store Secrets

If you write back-ends, one iron law: never store passwords in plaintext.

Hash, don't encrypt

Passwords should be hashed only—with bcrypt / Argon2 / PBKDF2, salted. Note "hash" ≠ "encrypt": encryption is reversible, hashing isn't. You shouldn't be (and shouldn't need to be) able to recover a user's password.

Our library offers hash tools (MD5/SHA digests) and bcrypt tool (purpose-built password hashing). Important: MD5/SHA are general digests, computed too fast—unsuitable to store passwords directly; they don't resist brute force. For storage use bcrypt / Argon2 / scrypt, the "slow hashes."

// Node.js: store password with bcrypt (correct way)
import bcrypt from 'bcrypt';
const saltRounds = 12;                 // higher = slower = safer, 12 is common
const hash = await bcrypt.hash(password, saltRounds);
// store hash in DB, not password

// verify at login
const ok = await bcrypt.compare(inputPassword, hashFromDb);

// Node.js: Argon2 (modern, recommended for new projects)
import argon2 from 'argon2';
const hash = await argon2.hash(password, {
  type: argon2.argon2id,
  memoryCost: 65536,   // 64 MB
  timeCost: 3,
  parallelism: 1,
});

Salt, pepper, and brute-force defense

Salt: a random per-user string mixed into the hash, stored in the DB. Makes identical passwords produce different hashes, defeating rainbow tables and stuffing. bcrypt/Argon2 salt automatically—just use them.
Pepper: a global key, not in the DB (env var / secret manager), prepended to the password before hashing. Even if the DB leaks, no pepper means hard to crack.
Rate limit & lockout: login endpoints must throttle, lock after failures, add CAPTCHA—block online brute force.
Timing attack: use constant-time comparison for hash verification (bcrypt.compare does this internally); don't compare with ==.

Encrypt only when reversibility is truly needed

For recoverable keys or user-authorized third-party tokens, use AES-256-GCM tool, with the key derived from a passphrase via PBKDF2, all local. But "user login password" should never be reversible—that's a design error.

Never log user passwords, never store them plaintext, never do anything beyond "strength check" on the front end. Front-end strength hints are UX only; real security is back-end hashing.

Compliance Reference: NIST's New Thinking

The US NIST 800-63B overturned the old "force change every 30 days" and "must include upper+lower+digit+symbol" routines. New guidance:

Length first (at least 8, longer recommended), not forced complexity combinations;
Don't force periodic changes (change only if leaked; forced rotation breeds weak passwords);
Check against known breach databases (k-anonymity API, never leaks the full password);
Allow paste (convenient for managers);
Limit max length only, don't restrict special characters.

The password strength tool follows these principles—not just "has a symbol," but length and whether it falls into common patterns.

Common Mistakes

Mistake	Consequence	Fix
One password everywhere	One leak, total collapse	Unique per site
`P@ssw0rd`-style swap	Dictionary seconds	Truly random / passphrase
In phone notes	Phone lost = done	Password manager
SMS-only 2FA	SIM-swap hijack	TOTP / hardware key
Short PIN as password	Brute-force seconds	12–16+ chars
Plaintext password in DB	One leak, fully exposed	bcrypt / Argon2 hash
MD5/SHA directly for passwords	Fast hash can't stop brute force	Use slow-hash algorithms

FAQ

Change passwords periodically? Not if no leak signs (per NIST). Forcing every 30 days breeds weak passwords or just changing the last digit. Change when a leak appears.

Passphrase or gibberish? Both work; key is length and randomness. Passphrase wins on memorability for master/handwritten; random gibberish for manager-auto-filled site passwords.

Found a site leaked—what now? Immediately change that site's password (and every site reusing it) → enable 2FA → check Have I Been Pwned for which emails were hit.

Forgot the manager's master password? Usually no recovery (that's the price of its security). So make the master a passphrase you truly remember, and keep an offline backup (handwritten, locked away).

Developer: which hashing algorithm? New project: Argon2id first; legacy compatibility: bcrypt (cost≥12). Avoid MD5/SHA directly for passwords.

Account Security Self-Check

1. Any reused passwords? → use /encode/password to generate unique strong ones, replace one by one
2. Long enough (≥12, 16+ recommended)? → lengthen if not
3. 2FA on? → prefer TOTP (/utils/totp) or Passkey, not SMS alone
4. Developer: passwords hashed? → /encode/bcrypt, not plaintext, not MD5/SHA
5. Master password memorable yet strong? → passphrase approach, offline backup
6. In a breach database? → periodically check Have I Been Pwned

Work through these six and your account security sits a notch above most people. On passwords, a day earlier is a day less worry. For related image/file privacy handling, see the data privacy guide.