歡迎光臨
每天分享高質量文章

使用者帳戶,授權和密碼管理的 12 個最佳實踐

來自:開源中國 協作翻譯

原文:12 best practices for user account,authorization and password management

連結:https://cloudplatform.googleblog.com/2018/01/12-best-practices-for-user-account.html

譯者:Tocy, lee, 邊城, 無若

賬戶管理,授權和密碼管理往往是很棘手的。對很多開發者來說,賬戶管理功能是一個暗角,不會引起足夠的重視。對於產品經理和使用者來說,產品的最終體驗往往超出預期。


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


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

序號
001

對密碼欄位做雜湊處理


對於賬戶管理,最重要的原則就是要安全地儲存使用者的敏感資訊,包括使用者的密碼。使用者的資料是神聖的,必須要適當的處理。


任何情況下都不要儲存明文密碼。你的服務中要藝術的雜湊處理密碼,並且不能解密密碼——例如,使用PBKDF2, Argon2, Scrypt, or Bcryp建立。這個雜湊值應該是對使用者唯一的登入憑證加鹽處理後的結果。


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


你應該假設你設計的系統最終會被洩露。問問你自己“如果我的資料今天洩露了,在使用我的服務或者他們使用的別的服務時,我的使用者的安全和隱私會受到威脅嗎?我們可以做些什麼來減輕這種潛在的資料洩露可能造成的危害?”


另一個需要考慮的事情:當使用者提供給你密碼之後,如果你能在任何時候產出一個使用者的明文密碼,那麼你的實現就是有問題的。


序號

002

盡可能允許第三方身份認證


第三方身份認證提供者使你可以依賴一個第三方值得信賴的服務認證使用者的身份。谷歌、Facebook和推特通常是可用的提供者。

除了已經存在的內部認證系統,你可以使用一個平臺(如 Firebase認證)接入一個第三方的認證服務。 Firebase認證有很多好處,如管理更簡單、攻擊入口更小和跨平臺的SDK。透過這個串列我們會提出很多好處,具體檢視 案例學習,這些例子可以讓你只需要一天就接入Firebase認證。


序號

003

區分使用者身份和使用者賬戶的概念


你的使用者不是電郵地址。他們不是電話號碼。他們不是由OAUTH響應提供的唯一ID。 你的使用者是你服務中獨有的個性化資料和體驗的聚合。設計良好的使用者管理系統在使用者個人資料的不同部分之間具有低耦合性和高內聚性。

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


實際上,為每個使用者提供一個內部全域性識別符號並透過該ID連結其配置檔案和身份驗證標識可能會有所幫助,而不是將其全部集中到一條記錄之中。


序號

004

允許多個身份關聯到單個使用者賬號


一開始使用使用者名稱和密碼認證登入到服務的使用者,後面可能會使用 Google Sign-In 來登入。他們並不知道這會建立多餘的賬號。類似地,由於某些原因,服務中的一個使用者可能會關聯到多個電子郵箱。如果能正確的分離使用者身份和認證資訊,將多個身份連結到同一個使用者就會變得簡單。


你的後臺需要考慮到使用者可能會透過一部分甚至所有途徑來透過註冊過程,但他們並沒有意識到在新的第三方身份沒有關聯到他們已經存在於系統中的賬號。


最簡單的實現是要求使用者提供一個共同的細節用於識別,比如電子郵件地址,電話或使用者名稱等。如果該資料與匹配到系統中現有的使用者,則要求他們認證已知身份並將新的 ID 關聯到已存在的賬號上。


序號

005

不要拒絕長密碼或者複雜的密碼


NIST 最近更新了關於密碼複雜度和強度的準則。如果你正在(或馬上會)使用高強度的雜湊演演算法來儲存密碼,很多問題就會迎刃而解。


不管輸入的內容有多長,雜湊演演算法都會生成固定長度的輸出,所以使用者可以使用他們喜歡的長密碼。如果你必須限制密碼長度,應該僅從服務支援的最大 POST 大小來考慮限制。嚴格地說,這通常大於 1M。


雜湊後的密碼由大家都知道的一小部分 ASCII 字元組成。就算不是,也很容易透過 Base64 把二進位制資料轉換過來。考慮到這一點,你應該允許使用者在密碼中隨意使用字元。如果有人想在密碼中使用克林貢語、表情字元和控制字元併在兩端加入空白字元,你應該沒有技術方面的理由來拒絕他們。


序號

006

不要為使用者名稱強加不合理的規則


有些網站或服務要求使用者名稱的字元數不低於兩三個字元,不允許不可見字元,前後不能有空格,這些都毫無道理。然而,有些網站會要求最小長度為 8 個字元,只允許使用 7 位(bit) 的 ASCII 字母和數字。


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


某些情況下最好的辦法是指定使用者名稱。如果你的服務中遇到這種情況,需要確保指定的使用者名稱對使用者來說很容易想起來也很容易告訴別人。


字母數字組合的 ID 應該避免視覺上不易識別的符號,比如“Il1O0”。同時還建議對隨機生成的字串進行字典掃描,確保使用者名稱中沒有意外嵌入一些資訊。這一原則同樣適用於自動生成的密碼。


序號

007

允許使用者更改他們的使用者名稱


在遺留系統或任何提供電子郵件帳戶的平臺中,不允許使用者更改其使用者名稱是非常常見的。這裡有很多好的理由支援不自動釋放使用者名稱以供重覆使用,但系統的長期使用者最終會給出一個很好的理由來使用不同的使用者名稱,並且他們可能不想建立新的帳戶。

你可以透過允許別名並讓你的使用者選擇主別名來滿足使用者期望更改其使用者名稱的願望。你可以在此功能之上應用所需的任何業務規則。


某些組織可能每年僅允許更改一次使用者名稱,或將阻止使用者顯示除主使用者名稱以外的任何內容。電郵供應商可能會確保使用者在將老使用者名稱從其帳戶中分離出來之前充分得瞭解了相關風險,或者可能完全禁止將老使用者名稱斷開連結。

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


序號

008

允許你的使用者刪除自己的賬號


相當數量的服務沒有用於使用者刪除其賬戶及相關資料的自助服務手段。使用者永久關閉帳戶並刪除所有個人資料有很多好的理由。


這些問題需要根據你的安全行和合規需求進行平衡,但大多數受監管的環境提供了有關資料保留的具體指導。避免合規和駭客攻擊的常見解決方案是讓使用者自己規劃其帳戶以備將來自動刪除。

在某些情況下,你可能需要遵照使用者的要求,及時刪除其資料。如果發生資料洩露,對於發生“已關閉”帳戶的資料洩露情況,你還可以大大提高你的曝光率。


序號

009

在會話長度上有意識地做決定


在安全驗證上常常被忽略的是會話長度。Google 作出了一些努力來確保使用者的行為併進行雙重檢查,這主要基於某些事件和行為。使用者可以有步驟地進一步加強他們的安全性。

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

考慮多久的時間使用者應該認證,並明確之前是不活躍的。如果有人進行密碼重置,就需要驗證所有活動會話的使用者身份。如果一個使用者更改核心方面的配置檔案或當他們執行敏感的行動,應該提示身份驗證或第二因素。並考慮不允許從多個裝置或位置登入是否有意義。


當你的服務使用者會話到期或需要重覆認證,提示使用者實時或提供一種機制來保護任何活動來儲存未儲存的最後驗證。使用者填寫表單,提交它一段時間後,發現他們所有的輸入已經丟失,他們必須再次登入,這是非常令人沮喪的。


序號

010

使用兩步校驗


考慮在選擇兩步校驗(也稱為雙因素授權或僅2FA)方法中之後使用者賬號被盜對使用者的實際影響。由於多重弱點,SMS 2FA認證已被NIST棄用,但它可能是你的使用者能接受的針對他們認為微不足道的服務時最安全的選擇。


盡你所能提供僅可能的最安全的2FA認證。啟用第三方身份識別提供商並搭載他們的2FA是一種簡單的可以無需大量開銷或經歷即可提高安全性的方法。


序號

011

使使用者ID不區分大小寫


你的使用者不關心,甚至可能不記得他們的使用者名稱準確的大小寫情況。使用者名稱應完全不區分大小寫。將所有使用者名稱和電郵地址以小寫形式儲存起來併在比較之前將所有輸入轉換為小寫字母都是很常見的。

智慧手機所代表的使用者裝置比例在不斷增加。他們大多數提供自動更正和自動大寫的純文字欄位。在UI層阻止這種行為可能不是理想的或完全有效的,並且你的服務應足夠健壯以處理無意中地自動大寫的電郵地址或使用者名稱。


序號

012

構建安全的身份認證系統


如果你正在使用的諸如Firebase Auth這樣的服務,那麼很多安全問題都已經自動為你處理了。但你的服務將始終需要正確設計以防止濫用。


核心考量因素包括實施密碼重置而不是密碼檢索、詳細的帳戶活動記錄、多次失敗登入嘗試之後鎖定賬戶以及對未識別的裝置或長時間處於空閑狀態的帳戶進行雙因素身份驗證。對安全認證系統來說還有更多細節,請參閱以下連結以獲取更多資訊。


●本文編號564,以後想閱讀這篇文章直接輸入564即可

●輸入m獲取到文章目錄

推薦↓↓↓

Linux學習

更多推薦18個技術類公眾微信

涵蓋:程式人生、演演算法與資料結構、駭客技術與網路安全、大資料技術、前端開發、Java、Python、Web開發、安卓開發、iOS開發、C/C++、.NET、Linux、資料庫、運維等。

贊(0)

分享創造快樂