Password input

Problem Context

• The user is signing in, reauthenticating before a sensitive action, confirming a current password before a change, entering a PIN-like memorized secret, or unlocking an account recovery step.
• Users may rely on browser autofill, password managers, generated passwords, copy and paste, hardware keyboards, mobile keyboards, or screen readers.
• The UI must balance shoulder-surfing risk with error recovery, especially when users need to inspect the value they typed.
• Authentication failures can leak whether an account exists if the product reports the username and password parts separately.
• Password entry connects to backend concerns such as protected transport, rate limiting, hashing, account lockout, recovery, MFA, and breach response even though the field itself only captures the secret.

Selection Rules

• Choose password input when the value is a password, passphrase, PIN-like memorized secret, current password, reauthentication secret, or credential confirmation value.
• Use autocomplete current-password for existing password entry, new-password for choosing or changing a password, and one-time-code for short-lived codes.
• Hide password values by default and give users a clear show and hide control when the surrounding context allows it.
• Use distinct show and hide labels when multiple password inputs are on one page.
• Disable spellcheck and automatic capitalization for password fields, especially when the value can become visible.
• Allow paste, autofill, and password managers; do not trap keyboard focus or require character-by-character typing.
• Accept long passwords and printable characters unless a documented technical constraint exists, and explain any constraint consistently wherever users create or enter the password.
• After failed sign-in, clear the password field and show a combined account-details message rather than saying the password alone is wrong.
• Move focus to the password error or error summary after submit without leaving the secret visible.
• Return the input type to password before submitting if the user had chosen to show it.
• Do not use password input for non-secret identifiers, email addresses, account labels, security answers, one-time recovery codes, or masked formatting of ordinary text.
• Do not show the password on review pages, receipts, logs, analytics, screenshots, or support tools.

Required States

• Initial hidden state with label, autocomplete purpose, spellcheck off, autocapitalization off, and show control.
• Focused hidden state that preserves native text editing and password-manager affordances.
• Visible state after the user chooses Show, with matching Hide control and visibility announcement.
• Pasted password-manager value state with the value accepted and not truncated.
• Caps Lock or keyboard-warning state that helps the user without changing the secret.
• Missing password error state connected to the field.
• Failed sign-in state with combined email and password error, cleared password value, and recovery link.
• Rate-limited or too many attempts state with next-step guidance and no secret disclosure.
• Successful submit state where the field has returned to type password and the value is not shown in review.
• Browser Back or session timeout state that does not restore a visible password.

Interaction Contract

• Typing, paste, selection, deletion, undo, and password-manager autofill work through native input behavior.
• The Show action changes only visibility, not the password value, cursor position, autocomplete purpose, or validation state.
• The Hide action obscures the secret immediately and updates the control label.
• Submitting while visible changes the field back to password type before the request leaves the page.
• A failed authentication clears the password field and does not reveal which credential part was wrong.
• Errors are reachable by keyboard and screen reader without reading the password value aloud.
• The field never stores the raw password in local storage, visible review, analytics events, or reusable page state.

Implementation Checklist

• Use a native input with type password, a visible label, autocomplete current-password for sign-in, spellcheck false, autocapitalize none or off, and aria-describedby for hints and errors.
• Implement Show and Hide as a real button with aria-controls, state-specific accessible labels, and a polite announcement if the visibility change needs to be announced.
• Allow paste, autofill, password-manager overlays, long values, spaces, and printable characters; do not use maxlength unless the user receives an explicit validation error instead of silent truncation.
• Use a combined credential failure message, clear the password after failed authentication, keep recovery links visible, and handle rate limiting without leaking account existence.
• Ensure the backend uses protected transport, rate limits attempts, and stores password verifiers as salted hashes with suitable work factors.
• Test password managers, browser autofill, paste, mobile keyboards, Caps Lock, show/hide, failed login, browser Back, session timeout, zoom, screen readers, high contrast, and multiple password inputs on one page.

Common Generated-UI Mistakes

• Using type text for passwords.
• Blocking paste or password-manager autofill.
• Leaving the password visible after submit, error, or browser Back.
• Showing Password incorrect when the account identifier was valid.
• Adding spellcheck or autocapitalization to a visible password field.
• Using maxlength so pasted manager values are silently truncated.
• Requiring confirm password for an existing-password sign-in field.
• Displaying password values on review pages, logs, support screens, screenshots, or analytics events.
• Using password input for ordinary masked identifiers or non-secret text.

Critique Questions

• Is this value truly an authentication secret, or is it ordinary text being hidden?
• Does the field use current-password, new-password, or one-time-code according to the task?
• Can a user paste or autofill from a password manager without losing characters?
• What happens to the password value after failed login, browser Back, session timeout, and visible submit?
• Does the error message avoid revealing whether the account identifier or password was wrong?
• Are spellcheck, autocapitalization, logs, analytics, screenshots, and support tools prevented from capturing the secret?