Modern website password rules that actually work

“Password must contain an uppercase letter, a number, a special character and cannot be one of your last five passwords.” Most of us have met this rule, sighed, and typed something like Welcome@123. That tells you the problem. A traditional website password policy often pushes people towards predictable patterns while annoying them into abandoning sign-up.

Security guidance has moved on. The US National Institute of Standards and Technology, in its Digital Identity Guidelines (SP 800-63B), and the UK’s National Cyber Security Centre both favour a simpler, stronger approach. Here is what that looks like when you apply it to a real website.

Why the old complexity rules backfired

Composition rules assume attackers guess randomly. They do not. Password-cracking tools are built around how humans behave, and humans respond to “add a symbol and a number” in very consistent ways: a capital at the start, a digit or year at the end, an @ in place of an a.

Forced periodic changes make it worse. When people must change a password every 60 or 90 days, they increment it: Summer@2025 becomes Summer@2026. An attacker who has seen one version can easily predict the next. Meanwhile, frustrated users write passwords on sticky notes or reuse them across sites.

Rule 1: Make length the main requirement

Each extra character multiplies the number of possible passwords, so length contributes far more to strength than a mandated symbol. Current guidance suggests:

• A minimum of 8 characters for user-chosen passwords, and preferably longer; many organisations now choose 12 or more, especially for staff and admin accounts.
• A generous maximum of at least 64 characters, so people can use passphrases and password managers.
• Acceptance of all printable characters, including spaces and Unicode, so a Hindi phrase or a sentence with spaces works.
• No silent truncation, where the site quietly cuts off characters beyond a limit.

A passphrase such as four or five unrelated words is long, memorable and much harder to guess than a short string stuffed with symbols.

Rule 2: Block passwords that are already known to attackers

The most valuable check is not what a password contains but whether it has appeared before. Attackers try leaked and common passwords first, so rejecting them removes the easiest wins.

What to screen against

1. Passwords from known data breaches. The Have I Been Pwned Pwned Passwords service offers a range query method where only the first five characters of a hash are sent, so the full password never leaves your server.
2. Lists of the most common passwords, such as 123456, password and qwerty variants.
3. Context-specific words: your business name, your domain, the user’s own email or username.
4. Repetitive or sequential strings like aaaaaaaa or 12345678.

When a password is rejected, say why in plain language: “This password has appeared in a data breach, so it is easy for attackers to guess. Please choose another.” Users accept rules they understand.

Rule 3: Stop forcing routine password changes

NIST guidance says verifiers should not require periodic password changes. Instead, require a change when there is evidence that a password has been compromised, such as:

• The account shows suspicious login activity.
• The password turns up in a new breach dataset during a check.
• The user reports phishing or a lost device.
• A staff member with shared knowledge of the credential leaves the business.

For internal admin accounts, pair this with two-factor authentication, which gives far more protection than rotation ever did.

Rule 4: Drop composition rules and hints

Remove mandatory mixes of character types. Also remove password hints and knowledge-based questions like “name of your first school”, which are either guessable or discoverable on social media.

This does not mean anything goes. The breached-password check and minimum length still catch the weak choices. The difference is that you block genuinely bad passwords rather than forcing everyone into the same predictable shape.

Designing the password field so good choices are easy

Policy is only half the story. The form itself strongly influences what people pick.

Friendly form details

• Allow pasting. Blocking paste breaks password managers and pushes people towards short passwords they can type.
• Offer a show-password toggle, so people can check a long passphrase without a separate confirm field.
• Use the right autocomplete values: new-password on sign-up and change forms, current-password on login, so browsers suggest and save strong passwords.
• Show a strength meter that reflects real guessability, such as one based on the open-source zxcvbn approach, rather than counting symbols.
• State the rules upfront beside the field, not only in an error after submit.

Where password rules fit in the bigger picture

A password policy only governs what people choose. It does nothing if the site stores passwords poorly or allows unlimited guessing. Make sure the backend uses a slow password hashing algorithm, throttles repeated attempts and offers two-factor authentication for accounts that matter. For many customer-facing flows, OTP or passkey sign-in can reduce reliance on passwords altogether.

A policy you can adopt this month

Here is a sensible starting point for most business websites and customer portals. Adjust with your developer for your risk level:

1. Minimum 8 characters for customers, 12 or more for staff and admins; maximum at least 64.
2. All characters allowed, including spaces; no truncation.
3. Reject breached, common and site-specific passwords with a clear explanation.
4. No composition rules, hints or security questions.
5. No scheduled expiry; forced reset only on signs of compromise.
6. Paste allowed, show-password toggle and correct autocomplete attributes.
7. Two-factor authentication required for every administrator.

If your sign-up forms still enforce the old rules, updating them is usually a small change. Our team can adjust existing flows as part of website development work or quote it through our pricing page.

Frequently asked questions

Is a 12-character password better than an 8-character complex one?

Generally yes, provided it is not a common phrase or leaked password. Extra length adds more possible combinations than swapping letters for symbols in predictable ways.

Why shouldn’t I force users to change passwords every 90 days?

Forced changes lead to small, predictable edits and more reuse. Current NIST guidance recommends changing passwords only when there is evidence of compromise.

Does checking passwords against breach lists expose them?

Not when done properly. The range query approach sends only a short hash prefix, and matching happens on your server, so the actual password is never shared.

Should special characters be banned from passwords?

No. Allow every printable character, including spaces. Restricting characters shrinks the pool of possible passwords and often signals poor storage practices behind the scenes.