先定規則再設計表格
密碼建立頁的目標，是協助顧客設定日後真正用得到的秘密。先弄清楚密碼是唯一登入因素，還是確實配合另一獨立因素。NIST SP 800-63B 的技術指引按此區分：單一因素密碼最低十五個字元；只作為多重因素流程一部分時可較短，但不得低於八個。這是 NIST 數碼身分範圍內的要求，可作為清晰的技術參考，不能說成香港網店的法定最低要求。寫表格文案前，先定下店方採用的最低長度、容許字元、最長長度及拒絕方式。註冊頁與伺服器必須執行相同規則，否則顧客會遇上前端說可以、提交時卻被拒的情況。
重視長度及選擇
不要只為滿足一個熟悉的強度指示，強迫顧客加入大寫字母、數字及符號。NIST 現行指引反對這類組合規則，也不建議無故定期更換密碼；它建議最長容許長度至少達六十四個字元，並容許空格，亦討論可列印字元及 Unicode。若舊系統仍有限制，應安排工程修正，而非在送出時才突然警告。要求應在輸入前可見。若密語被拒，用平實語言解釋原因，但不要向頁面透露某個具體密語是否出現在外洩清單。單靠裝飾性的「強」字標籤，可能誤把可預測模式評為安全。顧客需要的是能理解、而伺服器也能一致執行的規則。
攔截已知弱密碼
長度本身不足以阻止容易猜中的選擇。NIST 要求在建立或更改密碼時，把整個候選密碼與常用、預期或已外洩的值作比較，而不是因為密語內含一個常見詞就全部拒絕。這個分別對長密語尤其重要；粗暴禁止某個字詞，會錯誤排除很多互不相同的組合。團隊應訂出封鎖清單如何維護及測試。顧客可收到「這個密碼太常見或已知不安全，請另選一個」之類的訊息，但不要把輸入內容寫進日誌或客服工單。用受控測試值檢查拒絕流程，同時保留表格內非秘密資料，讓顧客不用重頭填寫。
支援管理工具、自動填入及貼上
密碼管理工具可以產生並保存獨立密碼，前提是表格容許它運作。NIST 指引要求支援密碼管理工具及自動填入，也建議容許貼上。W3C 對無障礙登入的解釋同樣指出，封鎖自動填入或貼上，可能使使用者失去輔助方法。不要禁止在密碼欄貼上，也不要用管理工具無法辨識的自製控制項取代正常欄位。欄位標籤要清楚，建立密碼與更改密碼的用途亦要分明。若服務面向不同裝置顧客，應在多種瀏覽器及管理工具上測試。本文處理建立密碼；既有的登入驗證碼流程另有測試需要。共同原則是安全設計不應迫使人記住或重打複雜秘密。
讓顧客檢查輸入
「顯示密碼」控制可協助顧客發現輸入錯誤，尤其在手機或輸入長密語時。NIST 建議在送出前提供顯示輸入內容的選項。控制項應是真正可操作的按鈕，狀態可供鍵盤及輔助技術使用者理解；切換顯示方式時不能清掉已輸入的內容。透過清楚標籤讓顧客自行決定是否讓旁人看到螢幕，不必每次彈出打斷流程的警告；共用裝置亦不宜預設顯示。要求須在輸入前說明，拒絕送出時指出實際問題，並把焦點帶到有用位置。錯誤訊息絕不能重印密碼。顧客修正後，也應清楚知道首次嘗試是否已建立帳戶。
審慎決定是否重複輸入
有些團隊因擔心打錯字而加入第二個密碼欄位，另一些則使用顯示密碼選項及管理工具。應先作選擇，再以真實裝置測試。W3C 關於重複輸入的解釋，在新建密碼沒有顯示的相關情況下容許重新輸入，但這不是要求所有顧客必須打兩次。若採用確認欄位，應支援貼上及自動填入；兩欄不符時指出問題，但不要同時清空。若顧客可自行顯示密碼，也要重新考慮強制重輸是否仍有價值。兩欄或可找出不一致，亦可能增加工作或與管理工具衝突。團隊應記下選擇原因，並檢查手機及鍵盤操作。
分清介面、傳輸與儲存
易用的表格只是帳戶安全的一部分。NIST 對索取密碼的受保護通道，以及能抵禦離線攻擊、配合鹽值和合適雜湊方法的儲存方式，均有技術要求。設計團隊不能因輸入欄看似很長，就假設後端會接受長密語、保留所有字元或安全儲存。以受控測試值檢查伺服器限制，包括長密語、空格，以及店方聲稱支援的字元。核實日誌、分析工具及錯誤報告不會收錄顧客輸入的秘密。密碼不應送到一般客服隊列供員工查看，也不能在帳戶紀錄顯示。這些檢查應由實作負責人與安全審查處理；公開頁面只可說明整套系統真正做到的規則。
用拒絕情境驗證流程
假設顧客從管理工具貼上長密語，表格起初接受，但舊資料庫欄位在後端悄悄截斷，最後只顯示「密碼無效」。顧客於是試着加符號。這不是顧客不懂設定密碼，而是公開規則與實作不一致。團隊應用測試帳戶重現問題，找出真正限制，修復整條處理路徑，修復期間也要提供清楚的錯誤訊息。若整個候選密語確實在弱密碼清單中，回應則應請顧客選另一個獨立密語。兩種失敗需要不同修正。還要記錄重試時哪些非秘密欄位仍保留，以及錯誤出現前帳戶有否已建立。
測試雙語及例外流程
英文及繁體中文頁面須表達同一套真實規則，但中文不必硬譯英文句式。測試管理工具產生的有效密碼、太短的選擇、封鎖清單內的值、含空格的長密語、已容許的 Unicode 字元，以及貼上內容。逐一核對頁面規則、伺服器結果和錯誤文案。若支援 Unicode，字元計算與正規化要按選定技術政策一致處理；NIST 討論以碼位計算長度，亦建議在接受 Unicode 時於雜湊前作正規化。不要無故要求顧客把所有中文字換成英文字母；若服務真的暫不支援，必須如實說明並安排修正。另要測試顯示密碼、焦點位置及網絡出錯後重試。驗收紀錄應列出實際結果，而非只打一個「表格通過」的勾。
讓政策可持續維護
上線後，指定一人負責公開文案，另一人負責伺服器政策，並共用變更紀錄。可審視封鎖清單流程、註冊錯誤情況及客服回報，但不應收集顧客真實密碼。規則改變時，須分開測試舊用戶與新註冊者；新的最低長度不能在沒有過渡安排下，被描述為已令所有現有帳戶失效。若有密碼外洩證據而需要更改，應清楚告知下一步，並與既有帳戶復原流程銜接。依照 NIST 指引，不宜只因日曆到了某日便例行強制換密碼。真正要檢驗的是：顧客能否建立獨立且合規的秘密、理解被拒原因，並於日後順利使用該密碼登入。
上線前檢查
- 讀者能否在實際頁面及慢速連線下完成決定？
- 團隊有否測試例外情況，並記錄修正負責人？
