[使用指南] 12 個 GCP 使用者帳戶、授權、密碼管理的方法
管理帳戶和密碼以及授權是相當困難的，開發者如果對帳戶管理沒有投入足夠的重視，產品經理和客戶往往容易覺得產品在帳戶管理方面的體驗不良。
Google Cloud Platform (GCP) 提供了多種工具幫助您在使用者帳戶的創建、安全處理和身份驗證（任何想使用您系統的人員，包含客戶或內部用戶）時做出正確的決策 。無論您是負責託管於 Google Kubernetes Engine 中的網站，還是使用 Firebase 的 Apigee 上的 API 亦或是其他需認證用戶的服務，這篇文章將列出 12 個最好的實踐，以確保您在 GCP 上能有一個安全的、可擴展、可用的帳戶認證系統。
1. 利用雜湊(hash)方法保護密碼
帳戶管理最重要的規則是安全地存儲敏感的用戶信息，包括密碼。您必須以謹慎的態度去適當的處理這些數據。
在任何情況下都不要儲存明碼，您的服務應該以加強的密碼算法所算出不可逆轉的雜湊值儲存，例如使用 PBKDF2、Argon2、Scrypt 或 Bcrypt 創建。密碼應該用對特定登錄憑證來說的唯一值進行加料式雜湊。不要使用過時的雜湊技術，如 MD5、SHA1，且在任何情況下都不應該使用可逆加密或嘗試創建自己的雜湊演算法。
您應該以系統最終會被入侵的思維來設計您的系統，可以試著問自己：“如果我的資料庫被洩露了，用戶的資料是否會在我提供的服務或其他服務中被盜取或濫用？我們可以採取什麼措施來降低資料庫洩漏可能造成的損害？”
此外，如果您可以在使用者提供給您密碼後的任何時間，以明碼的方式產生用戶密碼，這表示您在用戶帳戶和密碼管理的實踐上可能出了問題。
2. 如果可以，允許第三方身份提供商
第三方身份提供商讓您可以依靠可信的外部服務來驗證用戶的身份。Google、Facebook 和 Twitter 都是常用的提供商。
您可以透過 Firebase Auth 身份驗證等平台在現有的內部身份驗證系統上用外部身份進行身分認證。Firebase Auth 具有許多優點，包括更簡單的管理、更小的攻擊面、多平台 SDK。我們將在整個列表中涉及更多優點。想知道如何在短短一天內整合 Firebase Auth，請查看我們的案例分享。
3. 釐清用戶身份和用戶帳戶的概念
您的用戶不是電子郵件的地址也不是電話號碼，更不是由 OAUTH 回應時提供的唯一ID，事實上您的用戶能在您的服務上展現獨特的數據和經驗，所以在不同的用戶資料之間，設計良好的用戶管理系統是具有低耦合性(low coupling)和高內聚性(high cohesion)的。
清楚區分用戶帳戶和憑證的差異，將有效簡化：實施第三方身份提供商、允許用戶更改其用戶名、將多個身份鏈接到單個用戶帳戶的過程。實際上，為每個用戶提供一個內部全局標識符並通過該 ID 連接用戶個人資料和身份驗證標識，而不是將其全部集中到一條記錄中，這會有所幫助。
4. 允許多個身份鏈接到單個用戶帳戶
使用用戶名稱和密碼登入您的服務的用戶於一周內再次登入時可能會選擇 Google Sign-In，卻不了解這可能會創建重複的帳戶。同樣，用戶可能很合理的將多個電子郵件地址鏈接到您的服務。如果您能正確區分用戶身份和身份驗證的不同，那將多個身份鏈結到單個用戶帳戶會是件簡單的事。
您的後端需要考慮到，在用戶意識到他們正在使用和系統現有用戶無關的新的第三方身分前，已經填寫完註冊所需的部分或完整資料。為了克服上述問題，最簡單的方式是要求用戶提供常見的身分識別資料，例如電子郵件地址、電話、或是用戶名。如果該數據與您系統中的現有用戶資料相匹配，則要求用戶使用系統已知的身份進行身份驗證，並將新 ID 與系統現有帳戶鏈結。
5. 不要限制複雜或長的密碼
NIST 最近更新了密碼複雜性和強度的指導方針。由於您使用(或即將使用)強大的加密雜湊函式來儲存密碼，因此可以解決許多問題。無論密碼輸入的長度如何，雜湊後輸出的雜湊值會有固定長度，因此您的用戶所使用的密碼長度可以無上限。如果您一定要限制密碼長度，那麼只能根據服務器允許的最大 POST 大小進行限制，而這通常遠高於 1 MB。
您的雜湊值將包含一小部分已知的 ASCII 字元，如果沒有，您可以簡單得將二進位雜湊值轉換為 Base64 的編碼方式。考量到這一點，您應該允許用戶使用任何符號或字母作為密碼，不論是克林貢語、表情符號或兩端都有空格的控制符號，除了技術方面的理由外您都不該禁止它們。
6. 不要以不合理的規定限制用戶名稱
當網站或服務要求用戶名不能少於兩個或三個字、禁用隱藏字符和防止用戶名開頭和結尾處有空格，是合理的。但是有些網站會過度要求用戶名，例如用戶名不能少於8個字元，或者阻擋 7 位元 ASCII 字母和數字之外的任何字。
對用戶名限制嚴格的網站可能會為開發人員帶來方便，但這樣做會犧牲用戶的權益，甚至發生部分用戶離開的極端情形。
在某些情況下最好的方法是分配用戶名。如果您的服務屬於這種情況，請確保分配的用戶名是用戶友好的，讓用戶容易記憶和與他人溝通。字母、數字混用時應該避免在視覺上模棱兩可的符號，如 “Il1O0”。此外，建議您對隨機生成的字串進行字典掃描，以確保用戶名中不會含有非刻意產生的信息。這些準則同樣適用於自動產生的密碼。
7. 允許用戶更改他們的用戶名
在保留系統或任何提供電子郵件帳戶的平台中，不允許用戶更改用戶名是非常常見的。系統不會自動釋放用戶名以供重複使用有許多合理的理由，但長期用戶在不想創建新帳戶的情況下，為了使用不同的用戶名，最終會提出一個具有說服力的理由。
您可以透過允許使用者新增別名並讓他們選擇主別名來滿足用戶希望更改其用戶名的願望。您可以在此功能上實施所需的企業規範。某些組織可能每年只允許用戶更改一次用戶名，或者限制用戶顯示除了主用戶名以外的任何內容。電子郵件提供商可能會在用戶將舊用戶名從其帳戶中分離出來之前確保他們充分了解風險，或者徹底禁止將舊用戶名從帳戶中分離。
為您的平台選擇適當的規則，但要確保這些規則能讓您的用戶隨著時間成長和變化。
8. 允許您的用戶刪除他們的帳戶
有許多服務沒有能讓用戶刪除帳戶和相關資料的自助服務。用戶想永久關閉帳戶並刪除所有個人資料有很多因素。您需要將這些因素與您對系統安全及合規性的需求一同列入考量，但大多數受監管的環境都會提供有關數據保留的具體指導方針。避免合規和駭客攻擊的常見解決方式是讓用戶安排自己的帳戶以備將來自動刪除。
在某些情況下，您可能需要遵守用戶的要求，及時刪除其資料。當資料從”已關閉”帳戶被竊取時，您其他資料的曝光機會也會同時增加。
9. 訂定適當的工作階段長度
使用者對於網頁或服務的工作階段在安全性和認證的議題中常會被忽視。Google 付出許多努力來確保使用服務的用戶是本人，並且會根據特定的事件或行為進行複查。用戶可以採取某些措施進一步提高安全性。
您的服務讓工作階段無限期地開放便於非關鍵分析是合理的，但是應該有時間限度，超過時間後需再次向使用者要求輸入密碼、雙步驟驗證或其他資料以利驗證。
要去考慮在重新認證前，用戶能夠處於閒置狀態多久。如果用戶執行密碼重置，請驗證所有非閒置工作階段中的用戶身份。如果用戶更改個人資料中重要的部分，或者他們正在進行敏感操作，則立即進行身份驗證或雙步驟驗證。試著去思考禁止從多個裝置或位置登錄的合理性。
當用戶在您的服務的工作階段超過您的限制或需要重新驗證時，應該及時提供一種機制，保留驗證前未保存的活動。當用戶填寫完一份長表單，在提交前被要求重新登入，再次登入後卻發現所有先前輸入的內容都遺失，是很讓人挫折的。
10. 使用兩步驟驗證
當用戶資料不幸被竊取時，兩步驟驗證(或稱雙因素認證，簡稱 2FA)被認為能在帳戶保護方面帶來實質的影響。基於許多缺點，NIST已棄用 SMS 2FA 認證，然而，當您的用戶在使用較瑣碎的服務時，SMS 2FA 認證可能是最安全的選擇。提供您最安全的 2FA 認證。最簡單的方法是啟用第三方身份提供商並搭載他們的 2FA，可以在無需花費大量費用的情況下提高安全性。
11. 讓用戶ID不分大小寫
您的用戶並不會在意，甚至可能不記得他們用戶名大小寫的確切使用情況，因此用戶名應該不區分大小寫。將所有使用小寫字母當作用戶名和電子郵件地址的數據儲存起來，並在資料比對前把任何輸入的字母轉換為小寫字母是很簡單的。
使用智慧型手機的用戶比例不斷增加，而智慧型手機大多數提供自動校正和自動大寫的純文本字段。在 UI 方面防止這種行為可能不理想或不完全有效，您的服務應該要夠健全，足以處理自動大寫的電子郵件地址或用戶名。
12. 建構安全的身份驗證系統
如果您使用的是像 Firebase Auth 這樣的服務，會自動為您處理很多安全問題。但是，您的服務始終需要正確設計以防止濫用。需列入主要考量的設計包括:實施密碼重置而不是恢復原有的密碼、詳細得記錄帳戶活動、限制嘗試登入次數，並在嘗試登入失敗後鎖定帳戶，以及對未識別的設備或長時間處於閒置狀態的帳戶進行兩步驟驗證。要建構一個安全的認證系統還有許多需深入了解的資訊，想獲取更多相關內容請參閱以下連結。
閱讀更多
有許多傑出的資源可作為您在開發、更新或遷移您的帳戶和身份驗證管理系統過程中的指導方針。建議從以下文章開始閱讀：
• NIST 800-063B 涵蓋了認證和管理的生命週期管
• OWASP 不斷更新他們的密儲存備忘單
• 在認證備忘單中會更詳細地介紹 OWASP
• Google 的Firebase身份驗證網站提供豐富的指南、參考資料和範例程式庫
原文翻譯自：https://cloudplatform.googleblog.com/2018/01/12-best-practices-for-user-account.html
