ruby-on-rails devise-jwt - 設計的token_authenticatable安全嗎?





login gem (4)


您可以嘗試在您的API中使用rails4 ,它提供更高的安全性並使用設計3.1.0rc

對於令牌,會話商店,您可以訪問http://ruby.railstutorial.org/chapters/sign-in-sign-outhttp://blog.bigbinary.com/2013/03/19/cookies-on-rails.html更加明白。

最後,您應該通過這些加密和解密“ 無法解密存儲的加密數據 ”以獲得更高的安全性。

我正在使用Rails API構建一個簡單的api,並希望確保我在這裡正確的軌道。 我正在使用設計來處理登錄,並決定使用Devise的token_authenticatable選項,該選項生成您需要隨每個請求發送的API密鑰。

我將API與骨幹/牽線木偶前端配對,我一般想知道如何處理會話。 我的第一個想法是將api密鑰存儲在本地存儲或cookie中,並在頁面加載時檢索它,但是從安全的角度來看存儲api密鑰的方式是困擾我的。 通過查看本地存儲/ cookie或嗅探任何經過的請求來獲取api密鑰並不容易,並使用它來無限期地冒充該用戶? 我目前正在重置每次登錄時的api密鑰,但即使這樣也很頻繁 - 任何時候你登錄任何設備,這意味著你會被其他人登錄,這是一種痛苦。 如果我可以放棄這種重置,我覺得它可以從可用性的角度來改進。

我可能在這裡完全錯了(並且希望我是),任何人都可以解釋這種方式的認證是否可靠安全,如果不是,那將是一個什麼樣的好選擇呢? 總的來說,我正在尋找一種方法,我可以安全地保持用戶'登錄'訪問API,而無需經常強制重新授權。




token_authenticatable容易受到時間攻擊的影響, 本博文中對此進行了詳細解釋。 這些攻擊是從Devise 3.1中刪除token_authenticatable的原因。 有關詳細信息,請參閱plataformatec博客文章

要擁有最安全的令牌認證機制,令牌:

  1. 必須通過HTTPS發送。

  2. 密碼強度必須是隨機的。

  3. 必須安全地進行比較。

  4. 不得直接存儲在數據庫中。 只有令牌的哈希值才能存儲在那裡。 (記住,令牌=密碼。我們不在db中以明文形式存儲密碼,對吧?)

  5. 應該按照一些邏輯到期。

如果你放棄其中一些支持可用性的觀點,你最終會得到一種不那麼安全的機制。 就這麼簡單。 如果您滿足前三個要求並限制對數據庫的訪問,那麼您應該足夠安全。

擴展並解釋我的答案:

  1. 使用HTTPS 。 這絕對是最重要的一點,因為它涉及嗅探器。

    如果你不使用HTTPS,那麼很多都可能出錯。 例如:

    • 為了安全地傳輸用戶的憑據(用戶名/電子郵件/密碼),您必須使用摘要式身份驗證,但這些日子並沒有削減它,因為鹽漬哈希可能是強制性的

    • 在Rails 3中,cookie僅由Base64編碼覆蓋,因此可以很容易地顯示它們。 有關詳細信息,請參閱解碼Rails會話Cookie

      但是,從Rails 4開始,cookie存儲區被加密,因此數據經過數字驗證,對攻擊者來說無法讀取。 只要您的secret_key_base沒有洩露,Cookie就應該是安全的。

  2. 使用以下內容生成令牌:

    為了解釋為什麼這是必要的,我建議閱讀sysrandom的自述文件和博客文章如何在各種編程語言中生成安全隨機數

  3. 使用用戶的ID,電子郵件或其他屬性查找用戶記錄。 然後,將該用戶的令牌與請求的令牌與Devise.secure_compare(user.auth_token, params[:auth_token] 。如果您使用的是Rails 4.2.1+,則還可以使用ActiveSupport::SecurityUtils.secure_compare

    使用像User.find_by(auth_token: params[:auth_token])這樣的Rails查找程序找不到用戶記錄。 這很容易受到時間攻擊!

  4. 如果您要為每個用戶同時擁有多個應用程序/會話,那麼您有兩個選擇:

    • 將未加密的令牌存儲在數據庫中,以便可以在設備之間共享。 這是一種不好的做法,但我想你可以用UX的名義來做(如果你信任你的員工有DB訪問權限)。

    • 為每個用戶存儲盡可能多的加密令牌,以允許當前會話。 因此,如果要在2個不同的設備上允許2個會話,請在數據庫中保留2個不同的令牌哈希值。 這個選項實施起來不那麼簡單,但它肯定更安全。 它還具有以下優勢:允許您通過撤銷其令牌為用戶提供在特定設備中結束當前活動會話的選項(就像GitHub和Facebook一樣)。

  5. 應該有某種機制導致令牌過期。 在實施此機制時,請考慮用戶體驗與安全性之間的權衡。

    如果令牌未使用六個月,則Google會過期

    Facebook如果未使用兩個月就會過期

    使用Facebook SDK的原生移動應用程序將獲得長期訪問令牌,大約可以使用60天。 當使用您的應用程序的人向Facebook的服務器發出請求時,這些令牌將每天刷新一次。 如果沒有請求,則令牌將在大約60天后過期,並且該人將不得不再次通過登錄流程以獲得新令牌。

  6. 升級到Rails 4以使用其加密的cookie存儲。 如果你不能,那麼自己加密cookie商店,就像here建議的那樣。 將身份驗證令牌存儲在加密的Cookie存儲中絕對沒有問題。

您還應該有一個應急計劃,例如,rake任務可以重置令牌子集或數據庫中的每個令牌。

為了幫助您入門,您可以查看關於如何使用Devise實現令牌認證的這一要點 (由Devise的作者之一)。 最後, 關於保護API的Railscast應該會有所幫助。







使用新的哈希模式為Rails 4提供正確的代碼

validates :column_name, uniqueness: {scope: [:brand_id, :fuel_type_id]}




ruby-on-rails api authentication devise rails-api