設計你的密碼政策

你的密碼真的保護你嗎？#

在你的產品中，你可能需要依賴經典的身份驗證方法——密碼。雖然 密碼不會完全被取代，但相較於其他身份驗證方法，它們更容易受到 攻擊。你的密碼政策是否真的安全且合規？即使你熟悉各種密碼政策技術，疊加這些技術是否真的有效？

我們通過深入研究 NIST 規範、檢視領先的產品密碼政策並確保平衡的用戶體驗，來解決密碼政策設計和配置的複雜性。強調密碼合規的重要性，我們的目標是讓你擺脫與密碼策略相關的挑戰，並提供一個綜合過程，通過密碼與其他多因素身份驗證 (MFA) 驗證因素的無縫整合來確保賬戶安全。

用戶需要什麼樣的密碼？#

產品設計師經常會苦於如何確保他們的產品足夠安全，從而實施嚴格且複雜的密碼政策。例如，要求使用大寫和小寫字母、數字、甚至特殊字符的組合，或者要求員工定期更換密碼。

面對這些密碼要求，用戶很快會發出抱怨聲：「為什麼必須這麼複雜？記住我的密碼感覺像是一份全職工作！」這讓產品經理抓耳撓腮，思考是否更複雜的密碼政策就一定更好。我們來徹底分析全面的密碼政策的組成部分以找出答案。

在下一節中，我們將更深入探討密碼政策的細微差異，平衡安全性和用戶便利性。我們將探討如何定義合適的密碼要求，並提供數據支持的見解來支持我們的方法。

所有密碼因素的清單#

首先，在分析了眾多產品和 NIST 規範後，我們編輯了一份全面的密碼因素和設計建議清單。

我們大致將其分為三組：

1. 密碼設置要求：用戶設置密碼的最低要求。
2. 密碼安全監控：當檢測到密碼風險時進行提示和反饋。
3. 密碼用戶體驗：增強密碼創建和驗證過程中的用戶輸入體驗。

配置密碼體驗的工具#

也許你沒有耐心去檢查清單上的每一項。我們如果設計一個包含所有這些配置選項的強大密碼工具，可能會成為開發者的頭痛問題，比複雜的密碼政策更複雜。因此，我們將密碼因素進一步簡化為三個步驟。

第一步：丟棄不必要的規則#

如表所示，一些過時的密碼規則可能看起來提升了安全性，實際卻收益不大，往往會造成用戶的困惑和挫折。

• 避免限制用戶必須使用的字符組合；限制字符類型的數量就足夠了。例如，Facebook、Discord 和 Stripe 不要求特定字符類型的組合，而 Google 的密碼政策僅要求「至少兩種類型的字母、數字、符號」。
• 不定期強制用戶更改密碼，這將給用戶的記憶帶來不必要的負擔。相反，僅在有憑證可能被危害的風險時需要更改密碼。
• 在清晰的最低密碼要求和密碼強度計之間只選擇一個，以防止用戶誤解。
• 避免過早顯示過於複雜的規則，阻止用戶專注於不一定會發生的錯誤上。
• 避免使用密碼提示，防止給潛在攻擊者帶來便利。

第二步：為不同產品提供定制化選項#

我們提供了靈活的配置選項，適用於最低密碼政策，並推薦值以減少開發者的學習曲線，提供開箱即用的登入體驗。這些選項包括：

• 最小長度：默認值為 8 個字符，最少 1 個。
• 最少要求的字符類型：不建議限制，即設定為 4 種中的 1 種。
• 密碼限制詞彙：建議啟用所有限制。儘管用戶不能避免觸發相同的詞彙，但允許添加三個或更多不連續的字符來增加密碼的複雜性。這種添加增加了密碼的混亂性。
• 禁用洩漏密碼：使用可靠的洩漏密碼數據庫來支持，防止用戶使用相同的密碼以避免直接的目錄攻擊。

第三步：用固定值確保安全性#

對於無法自定義的參數，我們實施了備用邏輯來確保密碼安全。如果你有特定的自定義需求，請隨時告訴我們。

• 密碼驗證速度限制：我們限制了連續錯誤密碼驗證的次數和暫時暫停登入的冷卻時間。這可防止持續的密碼攻擊。此外，我們提供連續失敗密碼驗證的 webhook，你可以用它來發送郵件通知或者中止高風險的賬戶。
• 默認情況下，在重置密碼並刷新Token 之後，我們會清除其他設備上的會話。這一額外的安全層有助於防止未經授權的訪問，確保你的數據保持保密和保護。

結論#

通過這三個簡單的步驟，你可以簡化配置密碼體驗的過程，實現安全與用戶便利性的平衡。Logto 使設置安全且用戶友好的身份驗證系統變得簡單。敬請關注我們即將推出的 MFA 功能，以空前的方式掌控你的產品安全。