The password defaults that actually matter

You click the little key icon in your password manager, accept the generated password, and move on. That tiny act has probably protected more accounts than a decade of security lectures. But if you stop for one second and look at the defaults, the tools don't agree with each other.

1Password is commonly described as suggesting 20-character random passwords. Bitwarden's current generator documentation shows a CLI example using bw generate -uln --length 14, and its public generator presents 14 characters by default. KeePass has long populated new entries with 20-character generated passwords, though I can't verify the current default from an official May 2026 app build on this machine. Dashlane's public generator currently shows length 16, while Dashlane's March 24, 2026 support article says you can customize password length and save generator settings as the default. Chrome's Google Password Manager doesn't expose a normal length preference in its help page, but Chromium source currently defines generated password length as 15.

Free online password generators are even noisier. Norton shows 12. Many small web generators show 12. Some newer ones show 16. Some let you slide all the way to 64 and still start low.

That's the story. If the experts and tool vendors all know "longer is better," why do the defaults land at 12, 14, 15, 16, and 20? What are they optimizing for?

They're optimizing for different failures.

A password manager has to create something a website will accept. Websites still ship strange limits: no more than 16 characters, no spaces, no quotes, no symbols from this one subset, must include a number, must not start with a number, must include a symbol but not that symbol. A generator that always emits 30 characters with punctuation will bounce off more signup forms. A generator that defaults to 12 will work almost everywhere, but it leaves too much margin on the table. A generator that defaults to 20 is making the right bet for stored passwords: the user won't type it, so make it long.

The position of this post is simple: for passwords stored in a manager, length matters more than composition rules. Use random, unique, 20-character passwords when the site allows it. Drop to 16 only when a site complains. Use passphrases for the few secrets you actually need to remember. Turn on breach checks. Use passkeys where they're available. Stop caring whether the generated password has exactly one uppercase letter, one digit, and one symbol. That ritual was never the important part.

What NIST Actually Says In SP 800-63B Rev 4

First, a date correction. I can't verify the claim that the final NIST SP 800-63B Rev. 4 was published in December 2024. NIST's CSRC page for SP 800-63B-4 lists "Date Published: July 2025" and a document history entry of "07/31/25: SP 800-63B-4 (Final)." The hosted NIST HTML version shows an August 26, 2025 page timestamp. The August 21, 2024 document was a second public draft, not the final. So the guidance below cites the final SP 800-63B-4, not the 2024 draft.

The password section is Section 3.1.1, Passwords. It says passwords can be chosen by the subscriber or assigned randomly by the credential service provider. It also says that if a chosen password appears on a blocklist of common, expected, or compromised values, the user has to choose a different one. Then it says the quiet part loudly: other composition requirements shall not be imposed.

That means no blanket rule that every password must include uppercase, lowercase, a number, and a symbol. NIST isn't saying generated passwords shouldn't contain those characters. A good random generator can use a large character set. NIST is saying verifiers shouldn't force humans through a recipe and pretend the recipe is security.

The verifier requirements are the ones that matter for product teams:

NIST SP 800-63B-4 guidance	Where it appears	What it means in practice
Minimum length is 15 for passwords used as a single factor	Section 3.1.1.2	A plain password login should require at least 15 characters.
Passwords used only as part of MFA may be shorter, but not below 8	Section 3.1.1.2	I can't verify "8 for user-chosen passwords" as a general final-Rev.4 rule. The final text says 8 only for passwords used as part of MFA.
Maximum length should be at least 64	Section 3.1.1.2	Let password managers do their job. Don't cap people at 16.
Composition rules are out	Section 3.1.1 and 3.1.1.2	Don't require mixtures of character types.
Forced periodic rotation is out	Section 3.1.1.2	Don't make people change passwords every 90 days unless there's evidence of compromise.
Blocklist checks are in	Section 3.1.1.2	Compare new passwords against common, expected, and compromised passwords.
Security questions are out	Section 3.1.1.2	Don't replace a password with "first pet" trivia.

The blocklist requirement is important because it doesn't fight users with arbitrary formatting. It blocks passwords that are already known to be bad. NIST says the entire password should be checked, not substrings inside it. So a blocklist shouldn't reject correct-horse-battery because it contains horse; it should reject Password123! because that whole string is the kind of thing people choose when a form yells at them.

Appendix A, "Strength of Passwords," explains the rationale. NIST says analyses of breached password databases show that the benefit of composition rules is smaller than people assumed, while the usability and memorability costs are severe. It gives the exact pattern everyone has seen: a user who would pick password may pick Password1 or Password1! when forced to add a capital, a digit, and a symbol.

That isn't a clever password. It's a predictable password wearing a costume.

The Entropy Table

Entropy isn't moral goodness. It's not vibes. It's a way to describe how many possibilities an attacker has to search if the secret was generated uniformly at random from a known set.

One bit doubles the search space. Ten bits is about a thousand possibilities. Twenty bits is about a million. Forty bits is about a trillion. Once you're near 100 bits with a truly random password, the conversation is no longer about clever guessing. It's about whether the site stores passwords badly, whether you reuse them, whether someone tricks you into entering them on the wrong page, or whether your device is compromised.

The table below assumes uniformly random generation. It doesn't apply to human-made "random-looking" passwords, because humans don't sample evenly from the search space.

Secret type	Approximate entropy	What it means
4-digit PIN	13.3 bits	10,000 options. Brute-forced in milliseconds if there's no device lockout. Fine only when hardware rate-limits attempts.
6-digit PIN	19.9 bits	1,000,000 options. Seconds if there is no throttling. Useful for device unlock only because the device limits guesses.
8-char complex, letters plus digits plus about 20 symbols	~52 bits	Exact entropy for an 82-character pool is about 50.9 bits; full printable ASCII is about 52.4. Crackable offline in minutes to hours against fast hashes with serious GPU hardware.
12-char random, using a-zA-Z0-9	~72 bits	Good, but not the hill to die on in 2026. Against fast hashes, large current GPU rigs move this from absurd to imaginable; slow password hashing changes the picture.
16-char random, using a-zA-Z0-9	~96 bits	Beyond current feasibility for a properly random, unique password unless the storage is extremely weak and the attacker has unusual scale.
20-char random, using a-zA-Z0-9	~120 bits	Functionally unguessable for the foreseeable future. This is the right default for manager-stored passwords.
4-word Diceware passphrase, EFF long wordlist	~52 bits	Similar entropy to an 8-character full-ASCII random password, but far easier to remember.
6-word Diceware passphrase, EFF long wordlist	~77 bits	A strong memorized secret. EFF recommends six words for most passphrase uses.

The Diceware rows come from the wordlist size. The EFF long wordlist, published July 19, 2016, contains 7,776 words, which is 6^5. One word is log2(7776), about 12.9 bits. Four words is about 51.7 bits. Six words is about 77.5 bits. EFF's dice-generated passphrase guide recommends six words from the long list and gives the same rough 2^77 scale.

For current cracking speed, use humility. I can verify some RTX 5090 hashcat numbers, but I can't verify current benchmark numbers for every Argon2 setting that real services use. Argon2 is parameterized by memory, time, and parallelism, so a single "Argon2 speed" number is usually fake precision.

Here are numbers I can verify from Chick3nman's Hashcat v6.2.6-851 benchmark on an NVIDIA GeForce RTX 5090 FE, created February 10, 2025:

Hashcat mode	Verified RTX 5090 benchmark	Why you should care
NTLM, mode 1000	340.1 GH/s	Fast legacy hashes make short passwords melt.
SHA-256, mode 1400	28.35 GH/s	Raw general hashes are not password storage.
bcrypt, mode 3200, iterations 32	304.8 kH/s	Slower by design, but parameters matter.
PBKDF2-HMAC-SHA256, mode 10900, 999 iterations	11.16 MH/s	Iteration count matters a lot.
Cisco-IOS PBKDF2-SHA256, mode 9200, 19,999 iterations	556.7 kH/s	More work per guess buys time.
scrypt, mode 8900	7,760 H/s	Memory-hard designs change the economics.

Those numbers don't mean one RTX 5090 can search 72 bits tomorrow. They mean the storage method changes the slope. A fast unsalted hash turns GPU speed into raw guesses. A modern password hash slows each guess down. A website with online rate limits slows guessing even more. A passkey removes the password guessing problem entirely for that site.

But you don't control how every site stores passwords. That's why the manager-side rule should be boring: use more characters than you strictly need. Twenty random characters is cheap. You don't type them. Your manager does.

Why Character Count Beats Character Recipes

Suppose a generator uses 62 characters: uppercase letters, lowercase letters, and digits. Each character adds about 5.95 bits of entropy. Add one more random character and you multiply the search space by 62.

Now compare that with "must include a symbol." If the password is truly random and the symbol set is part of the generator's alphabet, symbols help because they expand the alphabet. But if the password is chosen by a person, the rule mostly teaches people where to place the symbol.

They put the capital letter first. They put the digits at the end. They put ! last. They reuse the same base word. They change Summer2025! to Summer2026! when the rotation timer goes off.

This is why composition rules feel more impressive than they are. They count categories. Attackers guess patterns.

Research has been pointing this way for years. The CHI 2011 paper Of Passwords and People: Measuring the Effect of Password-Composition Policies, published May 11, 2011, tested password policies with more than 5,000 participants. One of its useful findings was that a 16-character minimum without extra composition requirements produced less predictable passwords than a shorter policy with several required character classes, while also being easier for users on several measures.

NIST Appendix A lands in the same place. Composition rules nudge people into predictable transformations. Blocklists catch known bad choices. Longer minimums raise the floor. Rate limits reduce online guessing. Slow password hashing reduces offline guessing. Password managers make unique random passwords practical.

The real work is in those controls, not in making someone add # to a word they were already going to reuse.

The Defaults Are Telling On The Product

Once you know the tradeoff, the default disagreement becomes less mysterious.

1Password's current support pages explain how to generate and customize passwords, but I can't verify the exact current default length from an official support page or app build as of May 2026. Older official community guidance said 1Password's random password suggestion is usually 20 characters when a site doesn't provide its own rules, and recent third-party reviews still describe 20. Treat 20 as the commonly observed default, but check your installed app directly.

Bitwarden is easier to verify. Its current generator documentation includes the CLI example bw generate -uln --length 14, and its public web generator defaults to 14 characters. Bitwarden also warns that over-constraining minimum numbers and minimum special characters can reduce generated password strength unless you need to satisfy a site's requirements. That's a good warning, but 14 is still lower than I'd choose today.

KeePass is a little different because it's a local app with profile-based generation. The official KeePass password generator help says new entries automatically get a random password and that the properties are controlled by the "Automatically generated passwords for new entries" profile. I can't verify the current 20-character default from an official May 2026 app build here. Long-running reviews and example configs report 20 characters for new entries, but the practical advice is to open your profile and check.

Dashlane's public password generator currently shows length 16 in the rendered page. Dashlane's March 24, 2026 support article says the extension lets you choose length and save settings as the default. Sixteen is acceptable. Twenty is better when the site allows it.

Chrome is a different category. Google's Chrome help page explains how to use a suggested password, but it doesn't expose a normal "make generated passwords 20 characters" preference. In Chromium source, the password generator currently sets kDefaultPasswordLength = 15 in password_generator.cc. That is at least visible and current in source, but it still means Chrome isn't the place to tune a personal password policy.

The right reading isn't "this manager is good, that manager is bad." The right reading is that defaults are a compromise. They aim at the median broken signup form, not your ideal security posture.

So change the posture yourself.

What To Change In Your Password Manager Today

If your manager stores the password and autofills it, set the generator to 20 characters whenever you can. Use letters and digits at minimum. Include symbols if the site accepts them. Don't force exact counts of each class unless the site requires it.

For 1Password, the defaults are probably fine if you're seeing 20-character generated passwords. Still, open the generator and verify. If it's set below 20, bump it. If a specific site rejects the password, lower that one password to 16 or remove symbols before you lower your global habit.

For Bitwarden, change the generated password length from 14 to at least 16. I recommend 20. Keep uppercase, lowercase, and digits on. Use symbols if your common sites accept them. Keep "minimum numbers" and "minimum special" low unless a form requires exact composition. Bitwarden's own docs warn that extra constraints can reduce strength because they shrink the random choices the generator can make.

For KeePass, open the password generator profile used for automatically generated passwords for new entries. If it is 20, leave it. If it isn't, set it to 20 or more. KeePass gives you a lot of control, which is wonderful until you forget that you changed a profile five years ago.

For Dashlane, 16 is acceptable, but set the extension default to 20 if the sites you use tolerate it. Dashlane's support docs say you can save generator settings as default in the extension. Use that, because defaults only matter if you don't have to remember to change them every time.

For Chrome or Google Password Manager, use its suggested passwords rather than making up your own, but understand the tradeoff. I can't verify a current user-facing length preference in Chrome's help documentation. If you want a global 20-character policy, use a dedicated password manager.

For random free web generators, check the length before you copy. If it starts at 12, move it. The difference between 12 and 20 is not eight extra inconveniences. It's about 48 extra bits of entropy for a 62-character alphabet. That's a different planet.

There are also three settings that matter as much as generator length:

Use unique passwords for every site. Reuse is the failure that turns one leak into five logins.

Turn on your manager's breach monitoring if it has it. You want to know when a saved password appears in known breach data.

Protect the manager itself with a strong master password or passphrase, plus MFA or a passkey where supported. Your vault password is one of the few secrets you may actually need to remember.

HIBP K-Anonymity Is Worth Understanding

Have I Been Pwned's Pwned Passwords service is one of the few security ideas that feels clever in a way that survives contact with real life.

The problem is obvious: you want to check whether a password appears in a breach corpus, but you don't want to send the password to a third-party service. You also don't really want to send the full unsalted SHA-1 hash of the password, because that becomes a stable identifier for the password.

HIBP's answer is a k-anonymity range API. The current HIBP API documentation describes the Pwned Passwords range search. The client hashes the password locally with SHA-1, uppercases the hex digest, sends only the first five hex characters to https://api.pwnedpasswords.com/range/{prefix}, then receives all matching suffixes for that prefix. The client compares locally.

Cloudflare's February 21, 2018 post, Validating Leaked Passwords with k-Anonymity, explains the design. Five hex characters create 16^5, or 1,048,576, possible buckets. HIBP's current docs say a range search typically returns around 800 hash suffixes, and every prefix returns HTTP 200. HIBP also supports optional response padding so a network observer has less to infer from response size.

Here's the worked example using the intentionally bad password password.

First, hash it locally:

password
SHA-1: 5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8
prefix: 5BAA6
suffix: 1E4C9B93F3F0682250B6CF8331B7EE68FD8

Then ask HIBP for the prefix range:

GET https://api.pwnedpasswords.com/range/5BAA6

The response is a text list of suffixes and counts:

0018A45C4D1DEF81644B54AB7F969B88D65:1
...
1E4C9B93F3F0682250B6CF8331B7EE68FD8:many
...

Your browser, app, or password manager checks whether your suffix appears in that response. If it does, the password has appeared in HIBP's data. If it doesn't, HIBP didn't find it.

The password never leaves your device. The full hash never leaves your device. HIBP sees only a five-character prefix that matches many possible hashes. This isn't magic privacy. A service can still learn that someone at your IP searched a prefix. If your password is already in the corpus, the candidate set is narrower than the universe. But it is a very practical improvement over sending the password or full hash.

This is what breach-list checking should look like: local hashing, small disclosure, local comparison, and no drama.

Tooleras' password generator does not currently include HIBP k-anonymity integration. That's a feature gap, and it should be named as one rather than waved away.

Passphrases And Random Strings Aren't Rivals

Password arguments often turn into tiny religions. Passphrases versus random strings is one of them.

Don't pick a religion. Pick the right tool for the job.

If a password manager stores the secret, use a random string. Random strings are dense. A 20-character password drawn from letters and digits gives you about 120 bits of entropy before you even add symbols. You don't need it to be pronounceable. You don't need to remember whether the third word was river or ribbon. You need the manager to store it and paste it into the correct origin.

If a human has to remember the secret, use a passphrase generated from a real wordlist. A six-word EFF Diceware passphrase is long, typeable, and memorable with a little practice. It's a good fit for a password manager master password, full-disk encryption, an SSH key passphrase, or a device password you need to type.

The danger zone is the fake passphrase: a quote, a song lyric, a slogan, a Bible verse, a team chant, or four words you personally thought of while looking around the room. Those are not Diceware. Those are human choices, and human choices have patterns.

Good passphrases are random words. The random part is doing the work.

Good random strings are random characters. The random part is doing the work there too.

The difference is density. A Diceware word from a 7,776-word list gives about 12.9 bits. A random character from a 62-character alphabet gives about 5.95 bits. So a six-word passphrase is roughly 77.5 bits, while a 20-character random string is roughly 119 bits. The passphrase wins when you need memory. The random string wins when storage is delegated.

That tradeoff is honest, and it keeps you from doing silly things like trying to memorize 8xG7pQ2mZ9vL4cT1bR6s or storing panoramic nectar precut smith banana handclap for every shopping site.

Composition Rules Are Actively Harmful

Composition rules don't just fail to help as much as people think. In many settings, they actively push users toward worse behavior.

The classic rule says: minimum eight characters, at least one uppercase letter, one lowercase letter, one number, and one symbol. Users respond by making Password123!, Summer2026!, Companyname1!, or a reused base password with the last digit changed.

Those passwords pass the form. They fail the threat model.

NIST SP 800-63B-4 Section 3.1.1.2 says verifiers shall not impose composition rules such as requiring mixtures of different character types. Section 3.1.1 says other composition requirements shall not be imposed after the blocklist rule. Appendix A explains why: users respond predictably, and the usability cost is real.

The CHI 2011 password-composition study backs that up. It found many common beliefs about password composition and strength were inaccurate. It also found that longer minimums can beat shorter composition-heavy policies in both predictability and usability. That doesn't mean every long human-chosen password is good. It means length is a better floor than character-class theater.

Forced rotation has the same problem. If users must change passwords on a timer, they often mutate the old password. The attacker who knows Spring2025! doesn't have to search the whole universe to try Summer2025!, Spring2026!, and Spring2025!!.

NIST's final guidance says not to require periodic password changes. Force a change when there's evidence the authenticator has been compromised. That's the right tradeoff. Change because the secret may be known, not because a calendar flipped.

There is one place where composition still has a practical role: broken websites. If a bank requires a symbol, generate a password with a symbol. If an old payroll app only accepts 16 characters, use 16. If a site rejects punctuation, use letters and digits and make it longer. The manager's job is to satisfy the site while preserving as much entropy as possible.

The site should not be teaching humans to make passwords by recipe.

Passkeys Change The Shape Of The Problem

Passkeys deserve their own section because they're not just "better passwords." They're a different model.

WebAuthn, the web standard behind passkeys, uses public-key credentials. The W3C WebAuthn Level 3 Candidate Recommendation, published January 13, 2026, defines an API for creating and using scoped public-key credentials. In plain terms: when you register, your authenticator creates a key pair for that site. The site stores the public key. Your device, security key, operating system account, browser, or password manager keeps the private key. At login, the site sends a challenge, your authenticator signs it, and the site verifies the signature with the public key.

No shared password crosses the network. There is no password database for that account in the old sense. The credential is scoped to the relying party, so a fake page at the wrong domain can't use the credential for the real domain. That's why passkeys are phishing-resistant in a way passwords and one-time codes aren't.

The FIDO Alliance passkeys page describes a passkey as a FIDO credential that lets users sign in with the same process they use to unlock a device: biometric check, PIN, pattern, or device password. FIDO also distinguishes synced passkeys from device-bound passkeys. Synced passkeys can move across your devices through a provider such as iCloud Keychain, Google Password Manager, Windows, 1Password, Bitwarden, or Dashlane. Device-bound passkeys stay on a particular hardware authenticator, such as a security key.

That sync model is the tradeoff. Synced passkeys are much easier to adopt because losing one phone doesn't necessarily lock you out of every account. They rely on the security and recovery model of the passkey provider. Device-bound keys give tighter hardware control, but recovery becomes your problem. For most people, synced passkeys are the adoption path. For high-risk administrative access, device-bound authenticators still matter.

What happens when you lose your device? Usually one of three things:

You set up a new device with the same passkey provider account, and synced passkeys return.

You use another already-enrolled device to sign in and add a new passkey.

You fall back to account recovery, which is only as good as the site's recovery process.

That last line is the part people skip. Passkeys improve sign-in, but account recovery can still drag passwords, email links, support desks, phone numbers, and identity checks back into the story. A site with passkeys and weak recovery is still weaker than it looks.

Use passkeys where they're available, especially for email, cloud accounts, developer platforms, financial accounts, and your password manager itself. Keep multiple recovery paths. Don't delete your last working password or authenticator until you've confirmed the passkey works on another device.

Passkeys don't make password managers obsolete yet. They make password managers more important for the transition. A good manager can store passwords, TOTP codes, recovery codes, SSH keys, notes, and passkeys while the web catches up.

What Tooleras Ships Today

The password generator at tooleras.com/tools/password-generator is intentionally simple. It gives you length control, character class toggles, and a strength indicator.

That's useful. It lets you move the number that matters most. It lets you include or exclude character classes when a site has weird rules. It gives quick feedback as you adjust the settings.

It also doesn't do everything this article recommends.

It does not currently have a Diceware or EFF wordlist passphrase mode. So don't use it as your passphrase generator for a master password if what you want is true wordlist-based entropy.

It does not currently integrate with HIBP's k-anonymity API. So it won't tell you whether a generated or entered password appears in the Pwned Passwords corpus.

It does not replace a password manager. A generator can create a good secret. A manager stores unique secrets, fills them on the right origin, warns on reuse, and helps you rotate the ones that matter.

The honest use is this: use Tooleras when you need a quick random password with chosen length and character classes. Set the length to 20 when possible. Use your password manager as the long-term home. Use a real Diceware tool when you need a memorized passphrase.

FAQ

How long should my password be in 2026?

For passwords stored in a manager, use 20 random characters when the site allows it. Use 16 as the practical minimum for generated passwords on sites that complain. For a password you must remember, use a randomly generated six-word Diceware-style passphrase.

Is a passphrase better than a random password?

It depends on who stores it. If you store it in your head, a passphrase is usually better because you can remember it without making it predictable. If your password manager stores it, a random string is better because it packs more entropy into fewer characters.

Do I really need different passwords for every site?

Yes. Reuse is the failure that turns one exposed password into many exposed accounts. A password manager exists so uniqueness doesn't depend on memory.

What about 2FA?

Use it. MFA reduces damage when a password is phished, guessed, reused, or exposed. Prefer passkeys or hardware security keys for important accounts. Authenticator-app codes are still better than SMS codes. SMS is better than no second factor, but it shouldn't be your first choice for high-value accounts.

Are passkeys ready?

For major accounts that support them, yes. They're especially good for Google, Apple, Microsoft, GitHub, password managers, and financial or cloud services with mature recovery flows. They're not universal yet, and account recovery still matters, so keep your password manager organized during the transition.

Should I use symbols?

Use symbols if the site accepts them and your manager stores the password. But don't worship symbols. A 20-character letter-and-digit random password is stronger than an 8-character password with punctuation. Length and randomness do the heavy lifting.

Should I change all my passwords every 90 days?

No. Change a password when it may be compromised, when the service reports a breach, when your manager flags it, when you reused it somewhere else, or when you shared it and shouldn't have. Forced calendar rotation often creates predictable variants.

Is a 12-character generated password enough?

It's not a disaster, but it's not where I'd set a default in 2026. Twelve random characters can still be strong, especially with slow hashing and rate limits, but you don't pay much to use 16 or 20 in a manager. Take the extra margin.

What should my password manager master password be?

Use a unique passphrase generated from a real wordlist, ideally six words or more from the EFF long list or a comparable Diceware list. Write it down during setup and store that paper somewhere sensible until you're sure it's memorized. Turn on MFA or passkey login for the manager if available.

Is Chrome's password manager good enough?

It's much better than reusing human-made passwords. But it gives you less control than a dedicated manager, and I can't verify a current Chrome setting that lets users choose generated password length. If you care about a global 20-character default, use a dedicated manager.

Should I check my real passwords in online tools?

Don't paste real passwords into random web tools. HIBP's Pwned Passwords k-anonymity flow is designed for safer checking because only a five-character hash prefix is sent and comparison happens locally. Use a reputable manager's built-in breach check or HIBP's own flow, not an unknown checker.

What's the one setting I should change today?

Set generated password length to 20 characters. If your manager is Bitwarden, move it up from 14. If it's Dashlane, move it up from 16. If it's 1Password or KeePass, verify you're actually at 20 or more. Then fix reused passwords before you obsess over anything else.

Pick The Longer Default

The password default that actually matters is the one that changes what you'll do when you're in a hurry.

You won't run entropy math at every signup form. You won't remember which sites have sane storage. You won't know which database will be stolen three years from now. You will click the generated password and move on.

So make that click count.

Set the generator to 20. Stop giving composition rules more credit than they deserve. Use blocklists and breach checks. Use passphrases only where memory matters. Use passkeys when the site supports them and the recovery path makes sense.

The strong position is also the boring one: a unique, random, long password in a manager beats a short password with a symbol almost every time. Defaults should reflect that. Until they all do, change yours.