… the actor is creating an account or returning to sign in through account access. Where it fits, passwordless access or federated identity through a trusted provider spares the actor a secret to remember. A password depends on nothing outside the artifact, so the artifact asks for one, on its own or beside those options, in a field on a form. The actor types it from memory or a note, or lets a password manager fill it.

Problem

Artifacts that ask for a password often make it harder to create a good one and harder to enter it again. Character-class rules, short maximum lengths, blocked paste and forced changes push actors towards predictable passwords, reuse, and written notes, while hidden rules and masked input turn creation and sign-in into trial and error.

Forces

• Strength vs memorability: rules that demand a capital, a digit and a symbol produce predictable patterns such as a capitalised word followed by “1!”, and are hard to recall; length adds more strength for less effort.
• Privacy on screen vs checking what was typed: masking protects against someone looking over the actor’s shoulder, but hides typos; a second “confirm password” field doubles the typing without letting the actor see either entry.
• Password managers vs bespoke fields: managers generate and fill long unique passwords, but fail on fields that block paste, cap the length, or reject the characters they generate.
• Clear errors vs account discovery: telling the actor which of the username or password was wrong helps them fix it, and tells an attacker which accounts exist.

Solution

Ask for a password with a minimum length and a check against common and breached passwords, and no other rules. State the requirements beside the field before the actor types, let password managers fill, generate and paste, offer a control that shows the password instead of a second confirmation field, and when sign-in fails, say that the details did not match without saying which part was wrong.

Do not make the password rules stricter to get more security. A password alone does not protect against phishing; add a second factor or offer a passkey for accounts that need more protection.

In practice

Showing instead of confirming

Hide the password by default and give the field a “Show” button that reveals it. Once the actor can see what they typed, a second “Confirm password” field adds nothing, so leave it out. If a page has two password fields, as when changing a password, label each control by its field (“Show current password”). On phones, where the screen is easier to shield and typing errors are more common, showing the password by default is a reasonable variant. Some browsers and password managers add their own reveal control, so check that the field does not end up with two.

Working with password managers

Use type="password" with autocomplete="new-password" when creating a password and autocomplete="current-password" when entering one, and keep a username field with autocomplete="username" on the same form, even where it is hidden or pre-filled, so managers save the pair. Allow paste. Do not set maxlength, which silently cuts long generated passwords short. Turn off spellcheck and automatic capitalisation on the field. Publish /.well-known/change-password as a redirect to the change-password page so managers can send actors there directly.

Failed sign-in attempts

When the username and password do not match, say so once, without saying which part was wrong, and clear the password field. Slow down repeated attempts before locking the account: lockout lets anyone who knows a username lock its owner out. Where an account does lock, the NCSC suggests allowing 5 to 10 attempts first, and the message should point to account recovery.

Changing a password

Do not ask actors to change their password on a schedule; regular changes lead to small, predictable variations. Ask for a change only when there is evidence the password has been exposed. When an actor changes their password, ask for the current one first, and send a notice to their verified email address so they learn of a change they did not make.

Strength feedback

A strength meter is optional. If one is used, base it on how guessable the password is rather than on which character classes it contains, and say what would make it stronger. Let the actor continue with any password that meets the minimum and passes the blocklist.

Research on this pattern

• In a comparison of password policies, raising the minimum length gave larger security gains than requiring more character classes, and made password creation less difficult. This is the basis for a length minimum with no composition rules.
• Masking had a limited effect on sign-in success, and did not notably change entry time, deletions or the kind of typos made; a substantial minority of participants used the show toggle. This is the basis for hiding by default with a control to show, rather than for leaving the password visible.
• Meters of many visual designs led people to longer passwords, but only meters that scored strictly made passwords measurably harder to crack, and people found those meters more annoying. In a lab and field comparison, meters led to stronger passwords when people had to change a password for an account they cared about, and made no observable difference on low-value accounts, where people reused existing passwords. This is why a meter is optional.

Resources & references

• GOV.UK Design System. Passwords
• GOV.UK Design System. Password input
• National Cyber Security Centre. Password policy: updating your approach
• NIST (2025). SP 800-63B-4: Authenticators
• Nielsen Norman Group. Password creation: 3 ways to make it easier
• Baymard Institute. Password requirements and password reset
• web.dev. Sign-up form best practices