谷歌云平臺(GCP)提供了一些工具，能夠使你在產品創造、安全處理和用戶賬號(本文中指任何在你系統中注冊的人——消費者或者內部用戶)認證方面做出更好的決策。

不論你負責的是什么系統，部署在 Google Kubernetes Engine 上的WEB網站、 Apigee 上的API服務、使用 Firebase 的應用或者任何包含用戶認證的服務，這篇文章會提供最佳實踐，來保證你擁有一個安全的、可伸縮的、可用的賬戶認證系統。

1. 對密碼字段做哈希處理對于賬戶管理，最重要的原則就是要安全地存儲用戶的敏感信息，包括用戶的密碼。

用戶的數據是神圣的，必須要適當的處理。

任何情況下都不要存儲明文密碼。

你的服務中要藝術的哈希處理密碼，并且不能解密密碼——例如，使用 PBKDF2, Argon2, Scrypt, or Bcryp創建。

這個哈希值應該是對用戶唯一的登錄憑證加鹽處理后的結果。

不要使用過時的哈希處理技術如MD5、SHA1，并且在任何情況下都不應該使用可解密的算法或者嘗試發明哈希算法。

你應該假設你設計的系統最終會被泄露。

問問你自己“如果我的數據今天泄露了，在使用我的服務或者他們使用的別的服務時，我的用戶的安全和隱私會受到威脅嗎?我們可以做些什么來減輕這種潛在的數據泄露可能造成的危害?”另一個需要考慮的事情：當用戶提供給你密碼之后，如果你能在任何時候產出一個用戶的明文密碼，那么你的實現就是有問題的。

2. 盡可能允許第三方身份認證第三方身份認證提供者使你可以依賴一個第三方值得信賴的服務認證用戶的身份。

谷歌、Facebook和推特通常是可用的提供者。

除了已經存在的內部認證系統，你可以使用一個平臺(如 Firebase 認證)接入一個第三方的認證服務。

Firebase 認證有很多好處，如管理更簡單、攻擊入口更小和跨平臺的SDK。

通過這個列表我們會提出很多好處，具體查看 案例學習Firebase認證。

3. 區分用戶身份和用戶賬戶的概念你的用戶不是電郵地址。

他們不是電話號碼。

他們不是由OAUTH響應提供的唯一ID。

你的用戶是你服務中獨有的個性化數據和體驗的聚合。

設計良好的用戶管理系統在用戶個人資料的不同部分之間具有低耦合性和高內聚性。

保持用戶帳戶和證書的概念分離將大大簡化實施第三方認證提供商的過程、允許用戶更改其用戶名并將多個身份鏈接到單個用戶帳戶上。

實際上，為每個用戶提供一個內部全局標識符并通過該ID鏈接其配置文件和身份驗證標識可能會有所幫助，而不是將其全部集中到一條記錄之中。

4. 允許多個身份關聯到單個用戶賬號一開始使用 用戶名和密碼 認證登錄到服務的用戶，后面可能會使用 Google Sign-In 來登錄。

他們并不知道這會創建多余的賬號。

類似地，由于某些原因，服務中的一個用戶可能會關聯到多個電子郵箱。

如果能正確的分離用戶身份和認證信息，將 多個身份鏈接 到同一個用戶就會變得簡單。

你的后臺需要考慮到用戶可能會通過一部分甚至所有途徑來通過注冊過程，但他們并沒有意識到在新的第三方身份沒有關聯到他們已經存在于系統中的賬號。

最簡單的實現是要求用戶提供一個共同的細節用于識別，比如電子郵件地址，電話或用戶名等。

如果該數據與匹配到系統中現有的用戶，則要求他們認證已知身份并將新的 ID 關聯到已存在的賬號上。

5. 不要拒絕長密碼或者復雜的密碼NIST 最近更新了關于 密碼復雜度和強度 的準則。

如果你正在(或馬上會)使用高強度的散列算法來保存密碼，很多問題就會迎刃而解。

不管輸入的內容有多長，散列算法都會生成固定長度的輸出，所以用戶可以使用他們喜歡的長密碼。

如果你必須限制密碼長度，應該僅從服務支持的最大 POST 大小來考慮限制。

嚴格地說，這通常大于 1M。

散列后的密碼由大家都知道的一小部分 ASCII 字符組成。

就算不是，也很容易通過 Base64 把二進制數據轉換過來。

考慮到這一點，你應該允許用戶在密碼中隨意使用字符。

如果有人想在密碼中使用克林貢語、表情字符和控制字符并在兩端加入空白字符，你應該沒有技術方面的理由來拒絕他們。

6. 不要為用戶名強加不合理的規則有些網站或服務要求用戶名的字符數不低于兩三個字符，不允許不可見字符，前后不能有空格，這些都毫無道理。

然而，有些網站會要求最小長度為 8 個字符，只允許使用 7 位(bit) 的 ASCII 字母和數字。

在網站上嚴格限制用戶名，可能會為開發者帶來方便，但在某些極端情況下對用戶的要求會讓某些用戶望而卻步。

某些情況下最好的辦法是指定用戶名。

如果你的服務中遇到這種情況，需要確保指定的用戶名對用戶來說很容易想起來也很容易告訴別人。

字母數字組合的 ID 應該避免視覺上不易識別的符號，比如“Il1O0”。

同時還建議對隨機生成的字符串進行字典掃描，確保用戶名中沒有意外嵌入一些信息。

這一原則同樣適用于自動生成的密碼。

7. 允許用戶更改他們的用戶名在遺留系統或任何提供電子郵件帳戶的平臺中，不允許用戶更改其用戶名是非常常見的。

這里有很多 好的理由 支持不自動釋放用戶名以供重復使用，但系統的長期用戶最終會給出一個很好的理由來使用不同的用戶名，并且他們可能不想創建新的帳戶。

你可以通過允許別名并讓你的用戶選擇主別名來滿足用戶期望更改其用戶名的愿望。

你可以在此功能之上應用所需的任何業務規則。

某些組織可能每年僅允許更改一次用戶名，或將阻止用戶顯示除主用戶名以外的任何內容。

電郵供應商可能會確保用戶在將老用戶名從其帳戶中分離出來之前充分得了解了相關風險，或者可能完全禁止將老用戶名斷開鏈接。

為你的平臺選擇合適的規則，但要確保它們允許你的用戶隨著時間的推移而成長和改變。

8. 允許你的用戶刪除自己的賬號相當數量的服務沒有用于用戶刪除其賬戶及相關數據的自助服務手段。

用戶永久關閉帳戶并刪除所有個人數據有很多好的理由。

這些問題需要根據你的安全行和合規需求進行平衡，但大多數受監管的環境提供了有關數據保留的具體指導。

避免合規和黑客攻擊的常見解決方案是讓用戶自己規劃其帳戶以備將來自動刪除。

在某些情況下，你可能需要 遵照 用戶的要求，及時刪除其數據。

如果發生數據泄露，對于發生“已關閉”帳戶的數據泄露情況，你還可以大大提高你的曝光率。

9. 在會話長度上有意識地做決定在安全驗證上常常被忽略的是 會話長度 。

Google 作出了一些努力來 確保用戶的行為 并進行雙重檢查，這主要基于某些事件和行為。

用戶可以有步驟地 進一步加強他們的安全性 。

你的服務可以有明確的理由來保持會話，而不是非關鍵分析目的無限期開放，但是，應該有一個 門檻 來要求您輸入密碼、或第二個因素或其他用戶驗證。

考慮多久的時間用戶應該認證，并明確之前是不活躍的。

如果有人進行密碼重置，就需要驗證所有活動會話的用戶身份。

如果一個用戶更改核心方面的配置文件或當他們執行敏感的行動，應該提示身份驗證或第二因素。

并考慮不允許從多個設備或位置登錄是否有意義。

當你的服務用戶會話到期或需要重復認證，提示用戶實時或提供一種機制來保護任何活動來保存未保存的最后驗證。

用戶填寫表單，提交它一段時間后，發現他們所有的輸入已經丟失，他們必須再次登錄，這是非常令人沮喪的。