[譯]用戶帳戶、受權和密碼管理的 12 個最佳實踐

• 原文地址：12 best practices for user account, authorization and password management
• 原文做者：Google Cloud Platform
• 譯文出自：掘金翻譯計劃
• 本文永久連接：github.com/xitu/gold-m…
• 譯者：Wangalan30
• 校對者：ryouaki, Potpot

用戶帳戶、受權和密碼管理的 12 個最佳實踐

帳戶管理、受權和密碼管理問題能夠變得很棘手。對於不少開發者來講，帳戶管理還是一個盲區,並無獲得足夠的重視。而對於產品管理者和客戶來講，由此產生的體驗每每達不到預期的效果。

幸運的是，Google Cloud Platform (GCP) 上有幾個工具，能夠幫助你在圍繞用戶帳戶（在這裏指那些在你的系統中認證的客戶和內部用戶）進行的創新、安全處理和受權方面作出好的決定。不管你是在 Google Kubernetes Engine 上負責網站託管，仍是 Apigee 上的一個 API，亦或是 一個應用Firebase 或其餘擁有通過身份認證用戶服務的 APP，這篇文章都會爲你展現出最佳實踐，來確保你擁有一個安全、可擴展、可以使用的帳戶認證系統。

對密碼進行散列處理

帳戶管理最重要的準則是安全地存儲敏感的用戶信息，包括他們的密碼。你必須神聖地對待並恰當地處理這些數據。

不要在任何狀況下存儲明文密碼。相反，你的服務應該存儲通過散列處理以後的、不可逆轉的密碼 —— 好比，能夠用 PBKDF二、SHA三、Scrypt 或 Bcrypt 等這些散列算法。同時，散列時還要進行 加鹽 處理，同時，鹽值也不能和登錄用的驗證信息相同。不要用已經棄用的哈希技術好比 MDS 和 SHA1，而且，任何狀況下都不要使用可逆加密方式或者 試着發明本身的哈希算法。

在設計系統時，應該假設你的系統會受到攻擊，並以此爲前提設計系統。設計系統時要考慮「若是個人數據庫今天受損，用戶在我或者其餘服務上的安全和保障會有危險嗎？咱們怎樣作才能減少事件中的潛在損失。」

另一點：若是你可以根據用戶提供的密碼生成明文密碼，那麼你的系統就是有問題的。

若是能夠的話，容許第三方提供身份驗證

使用第三方提供身份驗證，你就能夠依賴一個可靠的外部服務來對用戶的身份進行驗證。Google、Facebook 和 Twitter 都是經常使用的身份驗證提供者。

你可使用 Firebase Auth 這樣的平臺在已有的身份驗證體系的基礎上再添加額外的身份驗證方式。使用 Firebase Auth 有許多好處，好比更簡單的管理、更小的受攻擊面和一個多平臺的 SDK。經過這個清單咱們能夠接觸更多的益處。查看咱們專爲企業設計的的 案例，可讓你在一日以內集成 Firebase Auth。

區分用戶身份和用戶帳戶的概念

你的用戶並非一個郵件地址，也不是一個電話號碼，更不是由一個 OAUTH 回覆提供的特有 ID。他們是你的服務中，全部與之相關的獨特、個性化的數據和經驗呈現的最終結果。一個設計優良的用戶管理系統在不一樣用戶的我的簡介之間低耦合且高內聚。

在概念上將用戶帳戶和證書區分開能夠極大地簡化使用第三方身份驗證的過程，容許用戶修改本身的用戶名，並關聯多個身份到單一用戶帳戶上。在實用階段，這樣可使咱們對每一個用戶都有一個內部的全局標識符，並經過這個 ID 將他們的我的簡介與身份驗證相關聯，而不是將它所有堆放在一條記錄裏。

容許單一用戶帳戶關聯多重身份

一個每星期用 用戶名和密碼 在你的服務上認證的用戶，每每會選擇下次登陸使用 Google 登陸，可是他們可能沒意識到這樣會建立重複的帳戶。一樣的，一個用戶可能將多個郵件地址鏈接到你的服務上。若是你可以正確地將用戶的身份和認證區分開，那麼 關聯多個身份 到一個單一用戶上將是一件十分簡單的事情。

你的系統須要考慮這樣一種狀況：當用戶已經進行了一部分或者已經完成了整個註冊過程以後，他們才意識到，他們正在使用一個與他們已有的帳戶徹底無關的新的第三方身份。要解決這個問題能夠簡單地要求客戶提供一份普通的身份細節，好比郵件地址、電話或用戶名等。若是這份數據與系統中已有的用戶相匹配，則須要他們使用已知的身份認證，並將新的 ID 關聯到他們已有的帳戶上。

不要限制較長或者複雜的密碼

NIST 最近在 密碼的複雜度和強度 上更新了指南。既然你正在（或者很快就要）使用一個強加密的哈希值來進行密碼存儲，那麼大部分的問題已經解決了。不管輸入內容的長短，哈希值總會生成一個固定長度的輸出值，因此你的用戶應該根據本身喜愛的長度設置本身的用戶密碼。若是你必須限制密碼的長度，請按照你的服務器所容許的 POST 的最大值來設置。實際來講。這一般超過1M。

你的哈希密碼將包含一小部分已知的 ASCII 碼。若是不是，你能夠輕易地將一個二進制的哈希值轉成 Base64。考慮到這一點，你應該容許你的用戶在設置密碼時自由地使用任何他們想要的字符。若是有人想要一個由 Klingon、Emoji 以及兩端帶有空格的控制字符組成的密碼，你不能因任何技術實現上的理由而拒絕他們。

不要對用戶名強加不合理的規則

若是一個網站或服務要求用戶名長度必須大於兩個或三個字 符、限制隱藏字符或不容許用戶名的兩端帶有空格，這都不屬於不合理的範疇。然而，有些網站的要求未免有些極端，好比，最小長度爲八個字符或不容許使用任何大於 7bit 的 ASCII 字母和數字。

一個對用戶名要求嚴格的站點會給開發者提供一些捷徑，但這倒是以用戶的損失爲代價的，同時，一些極端的狀況也會帶走必定數量的用戶。

有些狀況須要咱們分配用戶名。若是你的服務屬於這些狀況，要確保用戶名可以使用戶在回想或交流時感受到足夠友好。由字母和數字組成的 ID 應該儘可能避免會在視覺上會產生歧義的符號，好比「Il1O0」。同時，咱們建議你對全部隨機生成的字符串進行字典掃描，以確保沒有嵌入用戶名中的意外信息。這些相同的準則適用於自動生成的密碼。

容許用戶修改用戶名

使人廣泛感到驚訝的是，原有系統或是其餘提供郵箱帳戶的平臺都不容許用戶修改他們的用戶名。咱們有不少 正當理由 不容許重用已經自動回收的用戶名，可是若是你的長期用戶忽然想要換個新的用戶名，最好能不用另外新建一個帳戶。

你能夠容許使用別名，並讓你的用戶選擇一個首要的別名，以此來知足他們想要修改本身用戶名的要求。你能夠在此功能之上應用任何你須要的商務規則。有些系統可能會容許用戶一年修改一次用戶名或者只顯示用戶的別名。電子郵件服務提供商應該能夠確保用戶在將舊用戶名與他們的帳戶分離開，或是徹底禁止斷開舊用戶名以前，已經充分的瞭解了其中的風險。

爲你的平臺選擇正確的規則，可是要確保他們容許你的用戶隨着時間增加和變化。

讓你的用戶刪掉他們的帳戶

沒有提供自助服務的服務系統數量驚人，這對一個用戶來講就意味着刪掉他們的帳戶和相關數據。對一個用戶來講，永久地關掉一個帳戶並刪掉全部的我的數據有不少的好理由。這些需求點須要與你的安全性和順從性需求相平衡，但大多數受監管的環境都會提供有關數據存儲的相關指導。爲避免順從性以及黑客的關注，一個較廣泛的作法是讓用戶安排他們的帳戶，以便將來自動刪除。

在某些狀況下，你可能會 被合法地要求遵守 用戶的需求及時的刪掉他們的數據。一樣，當「已關閉」帳戶的數據泄漏時，你也會極大的增長你的曝光率。

在對話長度上作出理智的選擇

安全和認證中一個常常被忽視的方面是 會話長度。Google 在 確保用戶是他們所說的人 方面作了不少努力，並將基於某些事件或行爲進行二次確認。用戶能夠採起措施 進一步提升本身的安全度。

你的服務可能有充分的理由爲非關鍵的分析目的保持一段會話無限期開放，可是這應該有 門檻，要求輸入密碼，第二因素或其餘用戶驗證。

考慮一個用戶在從新認證以前須要保持多長時間的非活躍狀態。若是某人想要執行密碼重置，須要在全部活躍會話中驗證用戶身份。若是一個用戶想要更改他們我的信息的核心內容，或者當他們在執行一次敏感的行爲時，提示進行身份驗證或第二因素。要考慮不容許同時在不一樣設備或地址登陸是否有意義。

當你的服務終止用戶會話或須要再次驗證時，實時提示用戶或提供一種機制來保存自他們上次驗證後還沒來得及保存的所有活動。對用戶來講，當他們填好一份很長的表格並在以後提交，卻發現他們輸入的全部信息所有丟失且他們必須再次登陸，這是十分使人沮喪的。

使用兩步身份驗證

要考慮當用戶選擇 兩步驗證 (也稱兩因素驗證或只是 2FA)方法而帳戶被盜後的實際影響。因爲有許多缺陷，SMS 2FA 認證 被 NIST 反對，然而，它或許是你的用戶考慮到這是一項微不足道的服務時會接受的最安全的選擇了。請儘量提供你能提供的最安全的 2FA 認證。支持第三方身份驗證和在他們的 2FA 上面打包是個十分簡單的方法，使你可以不花費太多力氣就能提升你的安全度。

用戶 ID 不區分大小寫

你的用戶不會關心或者甚至可能並不記得他們確切的用戶名。用戶名應該徹底不區分大小寫。與輸入時將全部字符轉換爲小寫相比，存儲時將用戶名和郵件地址所有保存爲小寫顯得十分微不足道。

智能手機的使用表明用戶設備所佔的比重不斷增長。他們大多數提供純文本字段的自動更正和首字母自動大寫功能。

創建一個安全認證系統

若是你在使用一個像 Firebase Auth 同樣的設備，大量的安全隱患都會自動幫你處理。然而，你的設備老是須要正確地設計以防濫用。核心的問題包括實現 密碼重置而不是密碼檢索，詳細帳戶活動日誌，限制登陸嘗試率，屢次登陸嘗試不成功後鎖定帳戶以及需雙因素識別已長時間限制的未知設備或帳戶。安全認證系統還有不少方面，因此請查看下方的連接獲取更多信息。

進一步閱讀

還有不少優秀的可用資源能夠指導你的開發進程,更新或遷移你的帳戶和認證管理系統。我建議如下爲出發點:

• NIST 800-063B 包含認證和生命週期管理
• OWASP 持續更新密碼存儲備忘單
• OWASP 使用認證備忘單進行深刻研究
• Google 的 Firebase 認證網站有豐富的指南庫,參考資料和示例代碼

---

掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區，文章來源爲 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。