使用者賬戶、授權和密碼管理的 12 個最佳實踐
賬戶管理、授權和密碼管理問題可以變得很棘手。對於很多開發者來說，賬戶管理仍是一個盲區,並沒有得到足夠的重視。而對於產品管理者和客戶來說，由此產生的體驗往往達不到預期的效果。
幸運的是，Google Cloud Platform (GCP) 上有幾個工具，可以幫助你在圍繞使用者賬戶（在這裡指那些在你的系統中認證的客戶和內部使用者）進行的創新、安全處理和授權方面做出好的決定。無論你是在 Google Kubernetes Engine 上負責網站託管，還是 Apigee 上的一個 API，亦或是 一個應用Firebase 或其他擁有經過身份認證使用者服務的 APP，這篇文章都會為你展示出最佳實踐，來確保你擁有一個安全、可擴充套件、可使用的賬戶認證系統。
對密碼進行雜湊處理
賬戶管理最重要的準則是安全地儲存敏感的使用者資訊，包括他們的密碼。你必須神聖地對待並恰當地處理這些資料。
不要在任何情況下儲存明文密碼。相反，你的服務應該儲存經過雜湊處理之後的、不可逆轉的密碼 —— 比如，可以用 PBKDF2、SHA3、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、前端、後端、區塊鏈、產品、設計、人工智慧等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。