Testing a Password Policy: Does It Help Users or Just Annoy Them?

Every organisation has a password policy, and many of them make security worse. Rules that demand frequent changes push users toward predictable variations, rules that demand a symbol push users toward appending an exclamation mark, and rules that forbid pasted passwords break password managers, which are the single best tool users have. A policy should be judged by what users actually do under it, not by how strict it looks on paper. The Password Policy Tester lets you test a policy's rules against sample passwords, so you can see which passwords pass, which fail, and whether the failures are the passwords you actually want to block. Test with sample passwords only, never with real credentials, and never paste a production password into any tester.

The strongest evidence about password policy comes from observing behaviour, not from theory. When forced to change passwords every 90 days, most users make the smallest change that satisfies the rule, such as incrementing a digit, which an attacker who knows one old password can predict. When forced to include a symbol, most users add it at the end, which an attacker who tries common patterns will find quickly. A policy that instead requires length, checks new passwords against lists of breached and common passwords, and never forces periodic changes, tends to produce passwords that are both stronger and more memorable, because it asks users to do one hard thing, choose a long password, rather than many small annoying things.

How it works

A policy tester takes a set of rules, such as minimum length, required character classes, maximum length, and breached-password checks, and applies them to a set of sample passwords, reporting which pass and which fail under each rule. The useful output is not a single pass or fail, but the pattern: if every sample that fails does so only because of a missing symbol, while long passphrases also fail, the policy is blocking exactly the passwords it should encourage. A good tester also lets you compare policies side by side, so a proposed change can be evaluated before it is imposed on users, rather than discovered to be harmful after a thousand help-desk tickets.

How it works

Two checks matter more than most rule lists admit. The first is a breached-password check: a new password that has appeared in a known breach should be rejected, however long or complex it looks, because attackers try breached passwords first. The second is a minimum length that is high enough to matter, generally at least 12 to 14 characters for user-chosen passwords, with longer preferred. Character-class requirements add little once length and breach checks are in place, and they add friction that drives users toward predictable patterns, which is why modern guidance treats them as optional rather than essential.

Worked example

Worked example with sample values. Suppose a policy requires 12 characters minimum, one uppercase letter, one digit, and one symbol, and it is tested against 5 sample passwords. Sample 1 is a 4-word passphrase of 22 characters with no digit or symbol, and it fails 2 rules. Sample 2 is 9 characters with all classes, and it fails the length rule. Sample 3 is 14 characters with all classes, and it passes all 4 rules. Sample 4 is a breached password of 16 characters with all classes, and it passes the 4 rules but should fail a breach check. Sample 5 is 13 characters with all classes, and it passes. The result is 2 passes out of 5, or 40 percent passing, but the more important finding is that the passphrase, arguably the strongest sample, fails, while the breached password passes. The policy is filtering for the wrong thing. These are sample values for illustration, using sample passwords only.

Worked example

Revising the policy shows the improvement. Suppose the new policy requires 14 characters minimum and a breach check, with no character-class requirements. Sample 1, at 22 characters and not breached, now passes. Sample 2, at 9 characters, still fails on length. Sample 3 passes. Sample 4 fails the breach check. Sample 5, at 13 characters, now fails on length, which is a genuine trade-off: the longer minimum blocks a decent password. The new result is 2 passes out of 5, the same headline rate, but the passes are now the passphrase and the strong password, and the failures are a short password and a breached one. The headline rate did not change; the quality of the decisions did, which is why a tester should be read for patterns, not for a single percentage.

Mistakes to avoid

One common mistake is setting a maximum length that is too low, such as 16 or 20 characters, which blocks passphrases and password-manager output, and pushes users back toward short passwords. Modern systems should allow at least 64 characters. Another is forbidding spaces, which blocks passphrases for no security benefit. A third is requiring periodic changes without a breach or a reason, which, as described above, produces predictable variations. Each of these rules feels strict, and each of them weakens the passwords users actually choose.

Mistakes to avoid

A further mistake is testing a policy only against passwords the policy author invented, which tend to be the passwords the author already likes. Test against a diverse set: passphrases, manager-generated strings, common passwords, breached passwords, and the predictable variations users actually produce, such as a season plus a year. Also never test with real user passwords: a tester that receives real credentials becomes a new place where those credentials are exposed, and the test itself becomes a security incident. Sample passwords, chosen to cover the patterns that matter, are sufficient and safe.

Putting it into practice

Before changing a policy, test the current policy and the proposed policy against the same set of sample passwords, and compare the patterns, not just the pass rates. Pair the policy with the defences that matter most: breach checks at creation, a second factor for important accounts, and support for password managers, including allowing pasting. Announce changes with the reasoning, not just the rules, because users who understand that length matters will choose longer passwords voluntarily, while users who are only told to add a symbol will add an exclamation mark and resent the whole exercise.

Related tools and reading: Related tools and reading: the Password Generator and the Password Entropy Calculator cover neighbouring needs that pair naturally with this one, and the guide at [/blog/password-passphrase-vs-random-password/] extends the same topic with further background and examples for readers who want to go deeper.

Key points

• Judge a policy by what users actually do under it, not by how strict it looks
• Length and breach checks matter more than character-class requirements
• Forced periodic changes push users toward predictable variations
• Test with sample passwords only, never with real credentials

In short: j.udge a policy by what users actually do under it, not by how strict it looks

One habit ties all of this together: re-check after every change. A result is only as current as the input it was run on, so a fix, a redesign, or a new version of the underlying material deserves a fresh run rather than reliance on an old report. Keep the previous result alongside the new one, note what changed between them, and treat any new finding as a question to investigate rather than a verdict to accept or dismiss. That loop of checking, fixing, re-checking and recording is what turns a one-off test into a reliable routine, and it costs far less time than debugging a problem that a second check would have caught early.