為何你的密碼複雜度政策反而讓安全性更差(以及該如何改善)

如果你的網站仍要求使用者密碼必須「至少包含一個大寫字母、一個數字與一個特殊字元」,你其實正在實施已過時的安全做法。研究顯示,這些規則反而會讓密碼更脆弱。

為何你的密碼複雜度政策反而讓安全性更差(以及該如何改善)

儘管像是 NIST SP 800-63BOWASP Authentication Cheat Sheet 這些主流安全標準早已給出明確指引,許多網站與企業安全政策仍抱著 2000 年代初期的複雜度規則不放,反而忽略了像外洩密碼偵測這類真正能提升安全性的現代最佳實務。

安全專家真正怎麼說

最新的安全標準對於密碼複雜度其實非常清楚:

NIST SP 800-63B 指出:

“No other complexity requirements for memorized secrets SHOULD be imposed.”

“There should be no password composition rules limiting the type of characters permitted. There should be no requirement for upper or lower case or numbers or special characters.”

OWASP Authentication Cheat Sheet 也呼應這項指引,強調「長度」比「複雜度」更重要。

為什麼密碼複雜度規則會適得其反

1. 使用者行為可預測

當你要求「大寫 + 小寫 + 數字 + 符號」時,使用者不會產生真正隨機的密碼,而是遵循可預測模式:

  • password 變成 Password1!
  • john 變成 John123@
  • love 變成 Love2024#

問題在於: 這些模式攻擊者早就知道。密碼破解工具會優先測試這些轉換規則。

2. 使用者挫折感上升,最後放棄

複雜要求會造成密碼疲勞:使用者不是直接放棄註冊(影響業務成長),就是為了避免麻煩而到處重複使用同一組「看似複雜」的密碼。

3. 產生反效果的變通行為

複雜政策會把使用者推向更高風險的做法:

  • 不安全地記下密碼: 螢幕貼便條、手機未加密備忘錄,或在郵件草稿中寫 MyComplex123!@#
  • 跨系統重複使用密碼: 建立一組「超複雜」密碼例如 MyWork2024!@#,然後到處使用——一次外洩、全部淪陷
  • 可推測的遞增模式: Spring2024!Summer2024!Fall2024!——攻擊者拿到一組就能猜下一組
  • 個資加上複雜規則: CompanyName123!Hometown2024@,使用社群媒體上容易蒐集到的資訊

真正有效的方法:基礎原則

聚焦長度,而非複雜度

  • 使用者自選密碼最少 8 個字元
  • 最大長度至少 64 個字元,以支援像「correct horse battery staple is easier to remember than C0rr3ct!」這類密碼片語
  • 允許所有字元,包括 Unicode、空白與 emoji 🔒

註:對於高安全需求系統,NIST 允許依風險評估提高最小長度。

真正重要的安全措施

單靠一組簡單的 8 碼密碼並不足夠。以下才是實際能保護使用者的做法:

封鎖已外洩密碼

  • 使用 “Pwned Passwords” 等服務,比對超過 100 億組已知外洩密碼
  • 無論複雜度高低,都要封鎖像 password123 這種常見密碼
  • 這比複雜度規則更能阻止攻擊

速率限制與帳號保護

  • 限制連續失敗嘗試次數(依 NIST,最多 100 次)
  • 漸進式延遲(1 秒、2 秒、4 秒……)
  • 重複失敗後啟用 帳號鎖定政策

密碼強度回饋

  • 視覺化強度指示器,幫助使用者理解什麼是強密碼
  • 設定密碼時提供 即時回饋

改變遊戲規則:現代化驗證體驗

正確支援密碼管理器

你的登入表單應該:

  • 允許貼上 至密碼欄位(不要阻擋 Ctrl+V)
  • 使用標準 HTML:<input type="password">
  • 支援 Tab 導覽 於帳號/密碼欄位間切換
  • 避免自訂輸入元件 破壞自動填入

為何重要: 密碼管理器能為每個網站產生真正隨機且唯一的密碼——這正是資安專業人員所期望的。

多因素驗證(MFA)

微軟研究指出 MFA 可阻止 99.9% 的帳號入侵。即使密碼外洩,MFA 仍能提供保護。

Passkey:未來方向

Passkey 以綁定裝置的密碼學金鑰取代密碼本身。它具備:

  • 幾乎無法被釣魚
  • 自動為每個網站建立 唯一憑證
  • 不需使用者記憶

結論

我們理解,對企業組織來說,採用這些現代最佳實務會比在政策裡加一句「密碼必須含符號」更費工。

但要求使用者輸入 P@ssw0rd123! 而不是 correct horse battery staple,只會帶來 虛假的安全感,並讓使用者因挫折而採取不安全行為。

可行的前進路徑:

  1. 移除複雜度要求
  2. 導入外洩密碼檢查 與速率限制
  3. 設計能與 密碼管理器良好搭配 的登入表單
  4. 部署 MFA 提供實質防護
  5. 規劃以 Passkey 作為長期方案

你的使用者與整體安全防護,都會因此受益。

資料來源:NIST Special Publication 800-63B《Digital Identity Guidelines》與 OWASP Authentication Cheat Sheet