Passphrase Generator

Why Passphrases

A passphrase trades character density for memorability. velvet-harbor-quartz-lantern is 28 characters you can actually type on a TV remote, and its strength comes from the random *selection* of words, not from the words being obscure.

Words	Entropy (7,776-word list)	Comparable to
3	39 bits	7 random characters
4	52 bits	9 random characters
5	65 bits	11 random characters
6	78 bits	13 random characters
7	90 bits	15 random characters

Four words is the widely quoted minimum; six is the sensible floor for a master password or a disk encryption key.

The Randomness Has to Be Real

Choosing words yourself destroys the entropy. Human-chosen "random" words cluster hard around common nouns, and a phrase that means something to you is in a much smaller space than the word list suggests. Roll dice, or let a CSPRNG choose.

Assume the attacker knows the word list, the separator and the word count. Security comes from the number of possible selections, never from the method being secret.

Where Passphrases Beat Passwords

• Master passwords — you type it daily and can never look it up.
• Disk encryption — often typed before a password manager is available.
• SSH key passphrases — same problem.
• Device unlock and recovery codes — typed on the worst possible keyboards.

Everywhere else, a long random string is better, because a manager types it for you and length costs nothing.

Do Not "Improve" It

Capitalising the first letter, appending !, or swapping o for 0 adds a bit or two and makes the phrase harder to type. Add another word instead — that is worth 13 bits.

Where Passwords Actually Leak

Cause	Share of breaches	Mitigation
Reuse after another site's breach	Largest single cause	A unique password per site
Phishing	Large	A password manager (it will not autofill on the wrong domain)
Weak or guessable	Moderate	Length and real randomness
Server-side breach	Moderate	Not yours to control; 2FA limits the damage

Notice that three of the four are unaffected by how complex an individual password is. Reuse is the dominant risk, and the only fix is a manager.

Storing Them, If You Are the Server

``javascript // Argon2id is the current recommendation const hash = await argon2.hash(password, { type: argon2.argon2id, memoryCost: 19456, // 19 MiB timeCost: 2, parallelism: 1, }); `

Never store plaintext, never store a fast hash, never encrypt reversibly. Salt is per password and generated by the library. Peppering — a secret added outside the database — helps only if the pepper lives somewhere the database dump does not.

Rules Worth Dropping

NIST SP 800-63B now advises against several long-standing practices:

• Forced periodic rotation. It produces Password1, Password2` and nothing else.
• Composition rules. They shrink the search space by making the pattern predictable.
• Password hints and security questions. Both are usually easier to guess than the

password.

• Truncating length. Accept at least 64 characters; a passphrase should fit.

Check candidates against a breached-password list instead. That single control removes more risk than every composition rule combined.