Home / Knowledge hub / Password policy
Knowledge hub
Password policy
The rules on length, reuse and checking that decide which passwords you accept.
What it means
A password policy is the set of rules that decide which passwords your application accepts and how they are handled. It covers minimum and maximum length, which characters are allowed, whether passwords can be reused, and how a new password is checked.
Older policies leaned on complexity rules and forced changes every few months. Current NIST guidance moves away from both, and toward length, a check against known breached passwords and a firm limit on guessing attempts. The aim is to stop easy guesses without pushing people into patterns that are just as easy.
Why it matters
Weak or reused passwords are what credential stuffing and brute force attacks live on. A policy that allows common passwords, or blocks sensible long ones, directly raises the chance that one of your customers' accounts is taken over. Each of those is an account that a customer trusted you to protect.
A bad policy also hurts you in other ways. Forced rotation pushes people to add a number to the end of last month's password. Composition rules produce predictable patterns. Neither makes an account harder to break into, and both fill your support queue.
How it shows up
You meet it on sign-up, password change and reset screens, and in any administrator console that sets passwords. Check the maximum length is generous, since NIST says to allow at least 64 characters, that pasting is permitted for password managers, and that new passwords are compared with a breached-password list.
Two further points. Store passwords with a slow, salted hash such as Argon2 or bcrypt, never in plain text. And apply the same rules in every place a password can be set, including the reset flow and any API, because attackers use whichever one is weakest.
Questions people ask
Password policy, answered
What does NIST say a password policy should require?
NIST SP 800-63B advises a minimum length, allowing long passwords, screening against known compromised passwords, and not imposing composition rules or routine expiry. It also expects a limit on failed attempts.
Should we force passwords to expire?
Not on a calendar schedule. NIST advises changing a password when there is evidence of compromise, because routine forced changes tend to produce weaker, predictable passwords.
Are special characters and numbers still needed?
Not as a rule. Length and unpredictability matter more. Allow them, but do not insist on them, since insisting produces patterns such as a capital first letter and a number at the end.
Does a good policy replace multi-factor sign-in?
No. A strong password can still be phished or leaked. MFA limits the damage when it is, and a policy cannot do that on its own.
How do we test our policy?
Try the weakest password the form will take, a known breached one, and a very long one. Then try setting the same password through the reset flow and any API, to see whether the rules match.
Related
Terms that sit next to this one
Breached password check
Refusing passwords that already appear in public leaks.
Credential stuffing
Trying passwords leaked elsewhere, because people reuse them.
Brute force
Trying passwords or codes over and over until one of them works.
MFA
A second proof beyond the password, usually a code or a hardware key.
Argon2
A modern password hashing function that is slow and memory-hungry on purpose.
Do all your password paths agree?
Sign-up, change and reset flows are tested on the running app for weak rules and guessable passwords, and each finding carries the request and response that proved it. Ask us to run it on one of your applications.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.