安全管理用戶會話的最佳方式

這是關於會話管理的兩部分系列文章的第2部分。如果讀者理解JWT(JSON Web令牌)和用戶會話的一般概念,那麼可以在不閱讀第1部分的情況下閱讀第2部分。

第1部分:會話管理簡介,最常用會話流分析和最佳實踐

第2部分:分析安全且易於集成的新開源會話流

第1部分提供了會話管理的教育指南(如何在活動會話期間處理,存儲和更改身份驗證令牌),並討論了幾種常用的會話流程。但是,我們認為第1部分中提到的流程在大多數用例的安全性方面都是次優的。我們遇到了IETF(互聯網工程任務組)在RFC 6819中概念化的流程。我們已經採用了建議的流程,並根據其他人的要求構建了流程,為更廣泛的社區開放了我們的代碼。

在這篇文章中,我們將探索和分析會話流程,討論一些實現細節,並為您提供可自定義的庫。該庫已準備就緒,可在一天內與您的系統集成(目前可用於NodeJS和MySQL)。

建議的流程

使用短期訪問令牌旋轉刷新令牌

建議的Auth流程 – 單擊縮放

  • 訪問令牌是短暫的,刷新令牌是長期存在的。
  • 獲得新的刷新令牌時,舊的刷新和訪問令牌在後端無效並從前端刪除。正確地做到這一點並不簡單。請參閱後面討論的「實施說明」。
  • 如果用戶自願註銷,則從前端撤銷訪問和刷新令牌並清除。

損傷分析
關鍵的身份驗證令牌永遠暴露在兩個攻擊面,即前端和後端,偶爾暴露在傳輸之外。

被盜的身份證令的影響:
訪問令牌被盜:攻擊者將在短時間內進行未經授權的訪問(直到令牌到期)

刷新令牌被盜:盜竊檢測將使被盜刷新令牌失效,將損壞限制在很短的時間內

檢測盜竊:
訪問令牌被盜:此盜竊只能通過使用啟發式演算法或用戶通知服務提供商/開發者來檢測。

刷新令牌被盜:只要攻擊者和受害者在攻擊後至少使用刷新令牌,就可以檢測到盜竊。這通過以下示例說明。

  • 攻擊者已設法獲取受害者的刷新令牌–RT0。在訪問令牌(AT0)到期時,受害者和攻擊者都需要使用RT0來獲取一組新的令牌。
  • 如果攻擊者首先使用RT0,那麼他們將收到一個新的RT1和AT1,使用它時將使RT0無效。當受害者使用無效的RT0時,伺服器將收到一個明確的跡象,表明由於客戶端應該使用RT1而發生了盜竊。如果受害者首先使用RT0,則類似的參數有效。
  • 如果受害者和攻擊者同時使用RT0,則會得到(RT1,AT1),另一個(RT2,AT2)。其中任何一個使用新訪問令牌的下一個請求將使RT1或RT2無效,從而導致受害者或攻擊者最終(1)註銷。再次,這裡的後端將清楚地表明盜竊。

一旦檢測到:
訪問令牌不需要被撤銷,因為它們是短暫的。但是,如果需要,可以通過從資料庫中刪除不透明訪問令牌來撤銷它們。

通過從資料庫中刪除刷新令牌,可以輕鬆撤消該令牌。

這總結了對概念流程的討論。下面是一些額外的指示,要記住想要自己實現此流程的讀者。或者,我們在Github上提供了此流程的開源實現。

實施說明

  1. 後端在生成新對時會使先前的令牌無效。在前端沒有收到新令牌(無論出於何種原因)的情況下,它將繼續使用先前失效的令牌 – 導致用戶被註銷。為了防止這種情況,只有當前端使用新令牌時,後端才會使之前的令牌無效 – 確認其成功收到。
  2. 每次使用有效的RT時,系統都會生成一個新的不同刷新令牌(RT)。為了防止誤報(盜竊的跡象)和用戶註銷,必須考慮前端可能發生的競爭條件(2)。
  3. 如果刷新令牌被撤銷,那麼理想情況下也應該撤銷其訪問令牌。
  4. 檢測刷新令牌被盜不需要資料庫顯式存儲無效令牌。這可以通過使用父子層次結構構建刷新令牌來實現(請參閱Github實現)。
  5. 具有JWT訪問令牌的實現在空間和時間複雜度方面可以像第1部分中的會話流5那樣可擴展。我們只需要在資料庫中為每個設備的每個登錄用戶存儲一個刷新令牌。

這就是我們在會話管理方面的大部分問題。下面是一個GitHub存儲庫,其中包含處理所有實現問題的源代碼。它可根據您的要求進行高度自定義,並可快速集成到您的系統中。它在防止和檢測令牌盜竊方面也非常安全。我們很想知道您的想法 – 請發表評論或發送電子郵件給我們。

SuperToken圖書館

只要股票活 – 我們承諾支持它(修復錯誤,解決問題,添加功能和更新文檔)並做出響應(通過SO,電子郵件等)。

為了向我們的早期讀者展示一些額外的愛,我們提供以下專門的支持:

  • 對您當前的會話管理系統進行免費諮詢,包括識別漏洞並建議針對您的特定用例進行改進。
  • 免費支持SuperToken庫。如果您在實施,錯誤和自定義方面存在任何問題 – 我們將按需提供。

專用支持只能在2019年7月10日之前免費使用

如果您將其他人推薦到圖書館(任何貢獻或使用圖書館的人),我們將在7月以後為您和該人提供額外一個月的免費專用支持。人越多,支持越多(最多6個月)。請參閱Git自述文件以查看有關此內容的更多詳細信息。

最後的結論和建議

構建生產就緒會話管理解決方案非常重要。它需要深入的知識,並且在時間和金錢方面都很昂貴。許多開發人員沒有優先考慮會話管理 – 導致生產中的次優,不安全系統。

我們已經討論了這兩個帖子中的各種會話流程。根據要求,一個流程可能比其他流程更適合。一般而言,我們的建議如下:

對於處理非常敏感數據的服務(例如:股票交易平台或類似Ashley Madison),安全性可能優先於用戶體驗。理想的流程將是會話流程3和來自第1部分的會話流程4的組合。具體而言,使用短期訪問令牌,其活動使用將在一段有限的時間內延長到期時間。但是,這將要求用戶在令牌過期時重新登錄 – 這可能經常發生。

對於所有其他服務,上述流程可能是合適的。在此範圍內,建議使用JWT訪問令牌(以便更容易擴展)。但是,如果訪問令牌立即可以撤銷是很重要的,那麼請使用不透明訪問令牌。此外,通過使用雙因素身份驗證或無密碼登錄方法可以提高安全性。後者的好處是不要求用戶記住另一個密碼。

就是這樣請通過評測或發送電子郵件告訴我們您的想法。我們希望這很有用。

腳註

(1)如果使用不透明令牌,則立即註銷,否則它們將在新JWT的到期時間之後註銷。

(2)這是競爭條件問題:假設用戶已在瀏覽器中的Tab1和Tab2中打開了您的應用。這兩個選項卡共享同一組cookie。下圖演示了競爭條件如何導致用戶註銷。

資訊來源:由0x資訊編譯自HACKERNOON。版權歸作者所有,原文鏈接:https://hackernoon.com/the-best-way-to-securely-manage-user-sessions-91f27eeef460?source=collection_category—4——2———————–。未經許可,不得轉載
提示:投資有風險,入市需謹慎,本資訊不作為投資理財建議。請理性投資,切實提高風險防範意識;如有發現的違法犯罪線索,可積極向有關部門舉報反映。
你可能還喜歡