Password creation

Problem Context

• The user is registering, setting an initial password, resetting a forgotten password, changing a compromised password, or replacing a password after an account-security event.
• Users may use a password manager, browser-generated password, passphrase, copied value, mobile keyboard, or assistive technology.
• The system may need different rules for single-factor and MFA-backed accounts, but those rules must be clear wherever users create and later enter the password.
• Common-password, breached-password, service-name, username-derived, or organization-specific banned checks can reject a value that otherwise looks long enough.
• Password creation often sits near account recovery, MFA setup, passwordless options, and notification workflows, but it must not expose the new secret through reminders, email, logs, or review pages.

Selection Rules

• Choose password creation when the user must choose or replace a reusable password, passphrase, or memorized secret.
• Use autocomplete new-password for the new password field and current-password only for the old password field in a change flow.
• Encourage password-manager generation and allow paste, autofill, long values, spaces, and printable characters.
• State the minimum length and any true technical restrictions before the user starts typing.
• Do not set a short maximum length; if any upper bound exists, validate it with an error rather than silent truncation.
• Do not require arbitrary mixtures of uppercase, lowercase, numbers, and symbols as a substitute for real strength checks.
• Reject commonly used, expected, breached, service-name, username-derived, or organization-specific weak values with a correction reason.
• Use a strength meter only if it models guessability or known weak patterns; do not use a checklist that can be satisfied by predictable substitutions.
• Do not require routine password changes unless there is evidence of compromise or an authenticator change that requires rotation.
• Do not ask for password reminders, password reset questions, or email delivery of the password.
• If extra protection is needed, offer MFA or passwordless setup rather than piling on password restrictions.
• Never show the accepted password on review, confirmation, receipts, support tools, analytics, screenshots, or account summaries.

Required States

• Initial new-password state with purpose, autocomplete new-password, minimum length, paste support, show and hide control, and no character-class checklist.
• Generated password state where a password-manager value is accepted without blocking paste or truncation.
• Visible password state with matching Hide control and no spellcheck or autocapitalization.
• Too-short state with the entered value preserved and a field-level length message.
• Common password rejected state with a reason such as This password is commonly used.
• Breached password rejected state that explains the value has appeared in exposed-password data without logging the raw value.
• Service-name or username-derived rejected state with a reason that does not reveal the full banned list.
• Strong passphrase accepted state with spaces allowed and no symbol requirement.
• Submitted state where the password is no longer visible and the next step describes account security or MFA setup.
• Password reset state that uses a time-limited link or code and never sends the new password by email.

Interaction Contract

• Typing, paste, autofill, password-manager generation, deletion, and selection follow native input behavior.
• Show and Hide change only visibility and do not change the value, cursor, validation status, or autocomplete purpose.
• Validation reasons update after typing, paste, blur, or submit without exposing the raw password in logs or analytics.
• Rejected values remain editable long enough for correction but are not displayed elsewhere.
• Accepted passwords are submitted through protected transport and never appear on review pages or confirmation screens.
• If current password is required in a change flow, it is separate from new password and uses current-password autocomplete.
• Password creation can hand off to MFA, passkey, recovery, or account notification steps without weakening the password rules.

Implementation Checklist

• Define minimum length, maximum supported length, accepted character set, Unicode handling, blocklist source, breached-password check, service-specific banned terms, rate limit, storage hashing, and reset notification policy before designing the UI.
• Use native password inputs with visible labels, autocomplete new-password, spellcheck false, autocapitalize none or off, aria-describedby for guidance and errors, and a show and hide button.
• Allow paste and password-manager generation; test generated passwords longer than 64 characters, spaces, punctuation, Unicode, mobile keyboards, browser suggestions, and password-manager overlays.
• Reject known weak values through common, breached, service-name, username-derived, and organization-specific checks with concise reasons and recovery advice.
• Avoid character-class checklists, short maximum lengths, silent truncation, periodic rotation, reset questions, reminders, emailed passwords, and storage of raw password values.
• Ensure backend submission uses protected transport, rate-limited change and reset attempts, salted password hashing with suitable work factors, and account notifications after reset or security-sensitive changes.

Common Generated-UI Mistakes

• Using uppercase, lowercase, number, and symbol checklists as the main security signal.
• Blocking password-manager paste or generated passwords.
• Silently truncating long generated passwords.
• Rejecting spaces or Unicode without a documented technical reason.
• Accepting Password123 because it satisfies character classes.
• Forcing routine password rotation without compromise evidence.
• Asking for password reset questions or reminders.
• Sending the password by email after reset.
• Displaying the new password on review, logs, analytics, support tools, screenshots, or account summaries.

Critique Questions

• Is the user creating a new reusable secret, or entering an existing one?
• Does the field use autocomplete new-password and allow password-manager generation?
• Can users paste long generated passwords without truncation?
• Which common, breached, service-name, username-derived, or organization-specific values are blocked?
• Does rejection explain what to fix without publishing the banned list or encouraging trivial substitutions?
• Are character-class rules, periodic rotation, reminders, reset questions, and emailed passwords avoided?
• Where could the raw new password leak after submit?