Define the decision before the form
A password creation page should help a customer create a secret they can actually use again. Start by deciding whether the password is the only sign-in factor or part of a genuinely multi-factor flow. That distinction matters in NIST SP 800-63B: its verifier guidance calls for a minimum of 15 characters when a password is the single authentication factor, while passwords used only as part of multi-factor authentication may have a shorter minimum, never below eight. NIST sets technical requirements for its digital identity context; a Hong Kong shop should treat them as a well-defined benchmark, not as a claim of local legal obligation. Document the shop’s chosen minimum, supported characters, maximum length and rejection process before writing interface copy. The sign-up form and server must enforce the same policy, or customers will see promises the system cannot keep.
Prefer length and choice over puzzles
Do not force customers to add a capital letter, a digit and a symbol simply to satisfy a familiar-looking meter. NIST’s current guidance says verifiers should not impose such composition rules, and should not require arbitrary periodic password changes. It recommends permitting a maximum length of at least 64 characters and accepting spaces; its guidance also addresses printable characters and Unicode. A shop may have legacy limits, but those limits need an engineering plan rather than a hidden warning after submission. Show requirements before a person types. If a phrase is rejected, explain the reason in ordinary language, without exposing whether a particular secret appears in a breach collection. Avoid a decorative “strength” label that awards high marks to predictable patterns. The useful outcome is a policy customers can understand and the server can apply consistently.
Check against weak known choices
Length alone is not a complete screen for an easily guessed choice. NIST instructs verifiers to compare a proposed password with a blocklist of commonly used, expected or compromised values, using the entire candidate rather than rejecting every word that happens to occur inside it. That distinction matters for useful passphrases: a blanket ban on a common word can reject many otherwise distinct long phrases. Define how the blocklist is maintained and tested, and apply the check when a password is established or changed. The customer message can say that the chosen password is too common or known to be unsafe and ask for another, without displaying the entered secret in logs or support tickets. The team should test the rejection with controlled test values and ensure the form preserves non-secret account fields so the customer can retry without starting over.
Support managers, autofill and paste
A password manager can generate and store a unique secret, but only if the form lets it work. NIST says verifiers should allow password managers and autofill, and should permit pasting. The W3C accessible-authentication explanation likewise notes that blocking autofill or paste can prevent people from using assistance to complete authentication. Do not disable paste in the password field or replace a normal input with a custom control that managers cannot recognise. Label fields clearly and make the account-creation and password-change purposes unambiguous. Test several browser and manager combinations if the shop supports a broad customer base. This article concerns creating a password; the already existing sign-in code journey needs its own tests. The shared principle is that a security control should not force a person to memorise or retype a complex secret.
Let people inspect what they entered
A show-password control helps a person detect typing mistakes, especially on a phone or with a long phrase. NIST recommends offering an option to display the password while it is being entered and before submission. Make the control a real button with a state that can be understood by keyboard and assistive-technology users, and keep the field value intact when toggling. Explain the visible-screen trade-off through an understandable control label, not a modal warning that interrupts every user. Do not reveal the secret by default on a shared device. The same form should show requirements before entry, identify which requirement failed after a rejected submission, and return focus to a useful place. Never echo the secret into an error message. A customer should be able to correct a mistake without wondering whether the first attempt created an account.
Make confirmation a considered choice
Some teams add a second password field because they fear an unnoticed typo. Others rely on a show-password option and a password manager. Choose deliberately and test with real users and devices. The W3C redundant-entry explanation permits asking a person to re-enter a newly created undisplayed password in the relevant circumstance, but that exception is not an instruction to make every customer retype one. If confirmation is used, allow pasting and autofill and say which field differs without clearing both. If the page displays a password as a user-controlled option, consider whether forced duplication still adds value. A two-field design may catch a mismatch but can also cause unnecessary work or conflict with a manager. Record the reason for the chosen approach, and check that both keyboard and mobile users can complete it.
Separate policy from storage and transport
A usable form is only one part of account security. NIST calls for protected channels when requesting passwords and for password storage resistant to offline attacks using suitable salted hashing. The design team should not assume that a long input field means the back end accepts long secrets, preserves all characters, or stores them safely. Test server-side limits with controlled examples, including a long phrase, spaces and characters the shop says it supports. Confirm that logs, analytics and error reporting do not capture the entered secret. A password must not be sent to an ordinary support queue for staff to inspect, nor displayed in account records. These checks belong with the implementation owner and security review. The public form should state only rules that are true of the complete system, and should never promise absolute protection.
Work through a rejected choice
Imagine a customer pastes a long phrase from a manager into a registration form. The interface initially accepts it, but the server rejects it because a legacy database field silently truncates input. The customer receives “invalid password” and tries adding a symbol. That is not a customer education problem; it is a mismatch between published policy and implementation. The team should reproduce the case with a test account, identify the actual limit, repair the full path, and give a clear error while the repair is under way. If the phrase is rejected because the entire value is on a weak-password list, the response should instead ask for a different unique phrase. The two failures require different fixes. Record which fields survive a retry and whether any account was created before the error appeared.
Test both languages and exceptional paths
The English and Traditional Chinese pages should communicate the same actual policy without copying awkward sentence structure. Test a valid manager-generated password, a too-short choice, a blocklisted value, a long phrase with spaces, a permitted Unicode character and a pasted value. Check the visible rule, server result and error wording for each. If Unicode is supported, examine normalization and counting consistently with the chosen technical policy; NIST discusses counting code points and recommends a normalization process before hashing when Unicode is accepted. Do not tell customers to replace every Chinese character with English letters unless the service truly cannot handle them and has a documented correction plan. Test show-password behaviour, focus placement and the restart path after a network error. The acceptance record should show observed outcomes, not a generic “form passed” tick.
Keep the policy maintainable
After launch, assign one owner to the public wording and another to the server policy, with a shared change record. Review the blocklist process, account-creation error rates and support reports without collecting actual customer passwords. When a policy changes, test existing users separately from new registrations; a new minimum should not be presented as though it retroactively invalidates every existing account without a planned transition. If evidence of compromise requires a change, explain the next action clearly and coordinate with the existing recovery journey. Avoid routine forced rotation merely because a calendar interval has passed, in line with NIST’s guidance. The practical success measure is whether customers can create an acceptable unique secret, understand a rejection, and return later using the credentials they chose. Keep that outcome visible in every release review.
Release checks
- Can a person complete the decision using the real page and a slow connection?
- Have staff tested the exceptional path and recorded who owns its repair?
