Password policy research shows most major sites still miss best practice

At a glance

What this is: This is an analysis of Princeton University research on password policies across 120 major websites, with only 15 meeting the researchers’ best-practice criteria.

Why it matters: It matters because password policy design still shapes authentication risk for human IAM programmes, especially where weak defaults, user friction, and account recovery choices affect access security.

By the numbers:

• Of the 120 websites studied, only 15 were following best practices.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Bitwarden's analysis of Princeton's password policy study

Context

Password policy is the set of rules a service uses to decide how users create and reset passwords. The Princeton study examined 120 popular English-language websites and found that most still fail a basic test of strong password guidance, which leaves human identity controls exposed to predictable guessability and unnecessary friction.

For IAM teams, the issue is not simply whether a site requires more characters. The real governance problem is whether policy design reduces account takeover risk without forcing users into brittle patterns that undermine usability, reset behaviour, and ultimately authentication quality.

Key questions

Q: How should organisations design password policy for modern IAM programmes?

A: Start with length, blocklist common passwords, and avoid character-class rules that add friction without improving real guessability. Then validate the policy against actual account takeover risk, reset behaviour, and user support volume. The right policy makes strong passwords easy to choose and hard for attackers to predict.

Q: Why do strict password composition rules often fail in practice?

A: They usually increase memorisation burden without preventing reuse, predictable substitutions, or credential stuffing. Users respond by choosing patterns that satisfy the rule but still remain guessable. A policy that looks strict on paper can still leave authentication weak if it does not change attacker economics.

Q: What signals show that password policy is not working?

A: High reset volume, repeated failed logins, predictable password choices, and ongoing account takeover attempts are all warning signs. If users are bypassing the intended behaviour through help desk calls, note storage, or repeated changes, the policy is creating friction rather than resilience.

Q: What should identity teams prioritise after reviewing weak password policies?

A: They should prioritise the full authentication journey, including recovery, MFA enrolment, and account lockout behaviour, not just the password field. A good policy reduces guessability, supports user adoption, and limits the conditions that let attackers exploit reused or predictable credentials.

Technical breakdown

Password blocklists and composition rules: why they behave differently

Password blocklists reject common leaked passwords, while composition rules force users to meet character-class requirements such as digits, symbols, or mixed case. The study’s criteria favoured blocklists plus a length or strength-meter requirement, because composition rules often create predictable user workarounds without materially improving resistance to guessing. In identity terms, policy quality is about reducing guessability, not maximising complexity theatre. Good controls target the actual attack surface, which is password spraying, reuse, and credential stuffing, not abstract complexity metrics.

Practical implication: replace rigid composition rules with longer-password guidance, blocklists, and honest strength feedback.

Why password length and strength meters matter more than complexity rules

Length increases the search space an attacker must cover, while a reliable strength meter gives the user a signal about whether the chosen password is likely to resist guessing. The researchers treated a site as best practice if it required 8 or more characters, or used a meter that accurately measured resistance to guessing. That framing reflects a shift from ceremonial control to risk-based control. For human IAM, the goal is to improve actual authentication security, not just make policy look strict.

Practical implication: measure password policy outcomes against guessability and reuse risk, not against the presence of arbitrary character rules.

Password policy as a governance control, not just a login setting

Password policy is part of human identity governance because it shapes how easily users can create secure credentials, recover access, and avoid unsafe habits. When policy creates frustration, users often compensate through reuse, predictable patterns, or reliance on reset flows. That is why password policy belongs in IAM and security governance, not just application configuration. The study reinforces a broader point: authentication controls fail when they optimise for administrative simplicity rather than real-world user behaviour and adversary behaviour.

Practical implication: review password policy alongside account recovery, MFA enrolment, and authentication failure telemetry.

NHI Mgmt Group analysis

Weak password policy is still a human IAM governance problem, not a legacy UX detail. The Princeton findings show that many organisations still rely on password rules that look strict but do little to improve resistance to guessing. That matters because policy choices shape user behaviour, account takeover exposure, and help-desk burden at the same time. IAM teams should treat password guidance as a control surface, not a settings page.

Character-class requirements often create the appearance of security without changing attacker economics. Forcing symbols and mixed case can make passwords harder to remember while leaving reuse and predictability untouched. The better control is to increase entropy through length, blocklists, and honest strength measurement. Practitioners should stop equating policy complexity with identity assurance.

Password policy has to be evaluated in the context of account recovery and authentication recovery flows. A strong password rule that drives users into repeated resets or unsafe storage can increase downstream risk. Human identity programmes need to look at the full path from enrolment to reset to sign-in, because that is where weak policy becomes operational exposure. Practitioners should measure the full authentication journey, not only the password field.

Password strength is a shared responsibility between the service operator and the user, but the operator sets the constraints. The article’s central point is that organisations can either make strong passwords easy or force users into compensating behaviour. That choice directly affects phishing resilience, credential stuffing exposure, and support costs. Practitioners should treat password policy as part of broader identity risk governance.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• That pattern makes Top 10 NHI Issues a useful forward look at where identity governance breaks under operational pressure.

What this signals

Password policy drift: the problem is rarely the absence of a rule and more often the mismatch between policy intent and user behaviour. When organisations optimise for composition rules instead of guessability, they get brittle authentication and higher support load rather than better assurance.

This is a reminder that human IAM controls should be judged by measurable outcomes such as password reuse, reset frequency, and account takeover attempts. If those indicators do not improve, the policy is cosmetic and the programme is absorbing risk through convenience channels.

Password policy should now be treated as one layer in a broader authentication assurance stack that includes recovery flows, MFA, and monitoring for credential misuse. Teams that only tune the password field will keep rediscovering the same failure mode in a different form.

For practitioners

• Replace character-class rules with length-first policy Set minimum password length to at least 8 characters, then prefer longer passphrases where the application and user population permit it. Remove requirements that force digits, symbols, or mixed case unless a specific system constraint exists, because those rules often reduce usability without materially improving security.
• Deploy password blocklists at creation time Reject the most common leaked and easily guessed passwords before account creation completes. Keep the blocklist updated and make the rejection message clear so users understand why the password failed and can choose a stronger alternative.
• Use accurate strength meters only where they reflect guessability If you use a strength meter, validate that it measures resistance to guessing rather than just scoring complexity. Poor meters create false confidence and can encourage weak choices that still pass policy.
• Review reset and recovery journeys alongside password rules Check whether password resets, email-based recovery, and repeated login failures are pushing users toward unsafe habits. Password policy should be assessed together with recovery friction, MFA enrolment, and account lockout behaviour.

Key takeaways

• Most major websites still fail a basic password best-practice test, which shows that weak authentication design remains common.
• The study reinforces that password length, blocklists, and usable strength feedback matter more than cosmetic complexity rules.
• IAM teams should evaluate password policy together with recovery and MFA flows, because user friction often becomes the real control failure.

Key terms

• Password Blocklist: A password blocklist is a rejected list of common, leaked, or easily guessed passwords that users are prevented from choosing. In practice, it is a direct control against predictable credential selection and is more effective than forcing arbitrary character patterns that do not change guessability.
• Password Strength Meter: A password strength meter is a user-facing indicator that estimates how resistant a chosen password is to being guessed. The useful version measures actual guessability, not just character variety, and helps users make better choices without relying on brittle composition rules.
• Password Composition Rule: A password composition rule requires users to include specific character types such as numbers, symbols, or mixed case. These rules can improve superficial complexity, but they often create usability problems and predictable user workarounds if they are not paired with length and blocklist controls.
• Account Recovery Flow: An account recovery flow is the process used to regain access after a forgotten password, locked account, or authentication failure. It is part of identity security because weak recovery design can undermine even a strong password policy by making takeover or reset abuse easier.

What's in the full article

Bitwarden's full post covers the operational detail this post intentionally leaves for the source:

• Bitwarden's side-by-side comparison of its own bank-password criteria and the Princeton study methodology.
• The full discussion of the password-policy questions Bitwarden used when grading bank login experiences.
• Additional context on why password transparency matters for user behaviour and organisational accountability.
• Bitwarden's commentary on how its earlier banking review relates to the broader Princeton findings.

👉 Bitwarden's full post covers the study criteria, the website list, and the earlier banking comparison.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.