如何限制重複登入嘗試，同時避免誤鎖真正顧客

先判斷重複失敗代表甚麼

顧客登入表格常見兩種模式：有人對同一帳戶反覆猜密碼，也有人把少量已外洩密碼逐一試在大量帳戶上。只按 IP 地址限制，攻擊者換網絡便可能繞過；同一網絡的真顧客又可能一起受罰。OWASP 認證指引指出，失敗次數應與帳戶相關，而不應只記在來源 IP。NIST 現行數碼身分指引在相關驗證方式適用時，也要求限制單一帳戶上特定驗證器的連續失敗嘗試。香港中小企可參考這些設計原則，但不能把美國政府標準說成香港本地法律。

先列出所有提交憑證的入口：網站、手機程式、舊登入端點、重設密碼後的登入，以及第三方身分登入交接。限制應在真正判斷認證結果的伺服器執行；只在瀏覽器停用按鈕不算限制。要記錄系統如何找出帳戶、哪種驗證方式失敗、何時累計，以及何時清除次數。顧客輸錯電郵地址，不應悄悄增加別人的失敗紀錄；同一帳戶的大小寫或別名，也不應變成無限個新計數桶。這些歸屬規則必須先定，然後才談門檻。

設計能拖慢猜測而不易被濫用的回應

資料來源沒有規定所有商店都必須「錯五次就永久鎖帳戶」。NIST 對相關驗證器列出連續失敗不多於一百次的上限，亦明言可採用較低限制；一百不是建議各店照抄的設定。OWASP 要求同時考慮門檻、觀察時段及鎖定長度。實務上可在多次失敗後加入短暫等候，再隨失敗次數增加等候時間，並保留獨立的復原途徑。確切數值要按帳戶敏感程度、攻擊量及真顧客取得協助的速度決定。對外應說明顧客會遇到甚麼情況，無須公布每個內部門檻供攻擊者利用。

硬性鎖帳戶本身也可能變成攻擊：有人知道顧客電郵，便可故意觸發鎖定，令對方下單前無法登入。要測試鎖定對訂單紀錄、已存預約及緊急支援的影響。短暫延遲、額外驗證或另一種驗證方式，可能比立即封死帳戶更適合。不要把 CAPTCHA 當成完整防線；OWASP 把它視為有弱點的輔助控制，而難以使用的挑戰可能反過來擋住真顧客。如使用挑戰，應以鍵盤、螢幕閱讀器及手機實測，並為無法完成挑戰的人提供可用的後續途徑。

讓失敗提示與復原途徑互相配合

顧客需要知道是稍後重試、使用既有復原程序，還是聯絡支援。提示應交代下一步，同時避免洩露所猜的電郵是否對應帳戶。登入及復原入口對帳戶存在與否的回應應保持適當一致。若已達暫時限制，不能只顯示一般「密碼錯誤」，卻不說明再試會受到延遲。若帳戶被停用，恢復方式必須真實存在，而且人手或自助安排要符合頁面所說；不能即時收電郵的顧客也要有合理出路。客服在解除限制前需按文件核實求助者，否則復原途徑會拆掉原本的保護。

內部監察要分清密碼錯誤和服務故障，即使對外提示為免洩露帳戶資料而較簡短。同一帳戶大量失敗、少量密碼掃過許多帳戶，以及身分供應商出錯造成的失敗率上升，需要不同處理。調查紀錄可包括時間、結果、適當的帳戶參照、要求關聯識別及風險訊號；不要記下密碼、一次性驗證碼或完整工作階段權杖。日誌存取要受控，保存期按公司政策訂立。OWASP 的撞庫防護指引把多層防線與量度列為回應的一部分，但沒有單一數值可證明安全。監察攻擊跡象時，也要量度真顧客受影響情況。

以真實可測的顧客情境演練

假設網店發現同一顧客帳戶從多個網絡持續登入失敗。帳戶層面的計數上升，伺服器開始加入等候時間，同時拒絕錯誤憑證。網絡訊號可幫助分析人員看出攻擊分布，但不能取代帳戶控制。其後真顧客在家輸入正確密碼，系統仍須按已訂政策處理：只是暫時延遲，就清楚交代何時可重試；需要額外驗證，就確保能完成；驗證器已被停用，就走經核實的重新綁定或復原程序。客服不能因為來電者聽起來可信，就悄悄建立新工作階段。

演練也應包括家庭或辦公室網絡內有多名顧客使用不同帳戶的情況，因為粗略的 IP 限制可能令無辜用戶一起失敗。加入帳戶識別字大小寫不同、使用密碼管理器，以及在延遲期間啟動復原的人。預期結果未必是立即登入，而是有清晰下一步的安全路線。按選定政策檢查成功驗證後是否清除相關失敗紀錄，亦要防止一種驗證方式的失敗錯誤地重設或污染另一種方式的計數。NIST 對成功後重設次數有具體條件，實作者應按適用驗證器類型核對，不應複製一條籠統全域規則。

以端到端測試證明控制有效

用受控測試帳戶，經公開登入頁及所有其他客戶端測試政策。確認同一帳戶跨裝置的失敗會按規則累計，不同帳戶不會互相繼承次數，重新啟動或部署亦不會意外清掉限制。每個狀態的英文與繁體中文提示都要核對。復原路線須真正恢復存取並留下紀錄；客服應能說明下一步，但不能向未核實身分的來電者透露帳戶細節。發布後觀察真實成功登入及支援個案，再根據實際資料調整。目的在於提高猜測成本，同時保留正當用戶可走的路。

要記錄誰可更改門檻、緊急變更在公司內如何批准，以及哪些訊號會觸發檢討。登入限制既是程式，也是營運政策；一個很小的設定變動可大幅增加客服負擔，亦可能削弱防護。保留選定數值及理由的版本紀錄，但不公開可供利用的實作細節。登入方式改變或帳戶攻擊增加後應重檢政策。不能因為有計數器就宣稱完全免疫撞庫；攻擊者仍可分散嘗試，或使用有效的外洩憑證。可驗證的承諾較具體：重複失敗會觸發已設計的伺服器回應，而受影響顧客有經測試的出路。

發布前要決定當訊號互相矛盾時，營運人員如何處理。例如同一家庭可能因密碼管理器仍存舊密碼而連續失敗，遠端攻擊者亦可能產生相似次數。客服不能單憑計數猜原因。團隊應能查看時間、受影響帳戶及顧客自己的描述，但不應要求顧客說出密碼。若須等候，應交代如何通知；若提供重設程序，也要確保不會自動繞過正受調查的帳戶限制。用測試帳戶分別演練一次誤判及一次明顯攻擊，記下顧客看到的提示、伺服器決定與客服處理。這些證據比未測試復原途徑便宣稱門檻「安全」更有用。

政策檢討要把預防與事後回應分開。限制登入可減少猜測次數及速度，卻不能證明一次成功登入必然可信。若帳戶連續失敗後，突然在不尋常情境成功登入，公司可能需要按既定政策作另一層風險處理，例如通知帳戶持有人，或要求使用原有的額外驗證方式。也不應每次失敗都寄通知；惡意人士可反覆輸入已知電郵，造成收件匣被大量通知淹沒。要先決定哪些事件需要通知、由誰調查，以及顧客如何在不交出憑證的情況下回報陌生登入。檢討時應使用真正的營運觀察：多少正常用戶遇到延遲、多少客服個案需要復原，以及不同登入入口的分散失敗是否可見。尚未量度就應記為未知，不能視作門檻沒有副作用的證據。