Requirements should be fully shown before password entry
Aliases: upfront password rules · non-destructive password validation · password requirement visibility
What it is
Upfront password requirement disclosure shows every user-actionable condition that can determine acceptance before a person begins creating or changing a password, then provides specific feedback without clearing input. Hidden length, character, history, or prohibited-value rules make people discover the validator through failure, adding avoidable memory, rework, and abandonment costs.
Why it happens
Password creation already combines generation, memory, confirmation, and a security judgment. A late requirement forces someone to recall and restructure the attempted secret, while “invalid password” gives no next action. If interface and server policies drift, even apparently complete instructions produce repeated rejection. Persistent requirements and inline state turn a hidden puzzle into plannable constraints and expose implementation mismatch.
Studying it
Ask participants to register, change a password, and reset after recovery, comparing persistent upfront rules with post-submit revelation. Measure first-attempt success, error type, completion time, returns to instructions, field clearing, abandonment, and help seeking; test whether participants can state the constraints before entry. Separately probe boundary and prohibited values to reconcile client messages with server decisions. Submission success alone does not prove prior understanding.
Where it stops holding
“Fully shown” covers conditions that directly determine acceptance and that the user can satisfy; it does not require publishing an entire breached-password corpus, detection threshold, or internal rule that would aid evasion. When dynamic risk checks cannot be predicted, explain that additional verification may occur and provide a safe, actionable reason after triggering. Guidance must not copy the entered secret into logs, analytics, or assistive text.
Applying it
- Keep length, allowed-character, and other necessary conditions visible before the first password field receives input; do not hide them in a tooltip or behind the first failure.
- Mark each condition during entry; on failure preserve safe page state, focus the error, and explain correction in text rather than color alone.
- Have client and server consume one versioned policy definition, with contract tests for bounds, Unicode, paste, and prohibited values.
- Give actionable feedback for common or compromised values without echoing the secret or exposing the complete blocklist.