Memorable Password Generator

Words, Not Characters

A passphrase made of randomly chosen words is easier to remember and — at a sensible word count — stronger than the short mixed-character password most people actually use.

The arithmetic is straightforward. Entropy comes from the size of the word list and the number of words drawn, not from how the result looks:

Words	List of 2,048	List of 7,776 (Diceware)
3	33 bits	39 bits
4	44 bits	52 bits
5	55 bits	65 bits
6	66 bits	77 bits
7	77 bits	90 bits

Four words is the widely-cited minimum and is genuinely marginal against a well-resourced attacker. Five or six is where a passphrase becomes comfortable.

The Words Must Be Chosen Randomly

This is where passphrases usually fail. A phrase *you* pick is not random: it comes from song lyrics, film titles, your own vocabulary and your own associations, all of which an attacker can model. "correct horse battery staple" is famous precisely because it was generated, not chosen.

The generator above draws each word independently from the browser's cryptographic random source. If a phrase looks meaningful, that is coincidence — regenerate only if you dislike a word, never because it "seems too easy".

Where Passphrases Belong

• Your password manager's master password. You type it daily and it must be memorable.
• Full-disk encryption. Same reason.
• SSH key passphrases. Typed often enough that a random string becomes painful.
• Device unlock codes on anything without biometrics.

For everything else, a password manager stores a long random string and you never see it — memorability buys you nothing there.

Padding Rules Make It Worse

Adding a digit and a symbol to satisfy a policy adds a handful of bits and destroys the memorability that was the point. If a site demands them, append them in a fixed position and count them as zero entropy, because that is roughly what they are worth against anyone who knows the convention.

Length Limits Are the Real Obstacle

A six-word passphrase is 35–45 characters and some systems silently truncate at 16 or 20. When a passphrase is accepted at signup and rejected at login, truncation on one side and not the other is usually the cause.

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.