ruby-on-rails - session 和 cookie 在 Rails 中如何工作？

Question

我已经使用 Devise 来处理 Rails 应用程序上的身份验证有一段时间了，但从未真正理解它是如何工作的。因为 Devise 还使用 Rails 上设置的 session 存储配置，所以我假设这是一个有关 Rails session 处理的问题。

基本上，我是一个auth新手。我读过一些关于身份验证的文章，但大多数都涉及抽象库(他们谈论引擎、中间件等)，这对我来说没有多大意义。我真的在寻找较低级别的细节。

这是我目前所知道的..

我了解 cookie 和 session 。 Cookie 是存储在客户端的字符串，用于跨多个 HTTP 请求维护 session 。

这是我对身份验证的基本理解(如果我错了，请纠正我):

1. 当用户登录时，我们将 SSL 加密请求发送到服务器。如果凭据有效，我们会在数据库(或任何其他数据存储)上保存一个名为 session ID 的随机字符串，作为与用户 ID 关联的有效 session ID。该 session ID 在用户每次登录/注销时都会更改。

2. 将该 session ID 保存到数据存储后，我们返回一个响应，要求浏览器使用该 session ID 设置 Cookie。然后，该 session ID 与用户 ID 一起将被发送到域以进行连续请求，直到过期。对于每个请求，我们的服务器都会检查 header 中的 session ID，并验证该 session ID 对于该用户 ID 是否有效。如果是，则认为该用户已通过身份验证。

这是我的问题:

1. 我读到，默认情况下从 Rails 2 开始，它现在使用 CookieStore(而不是 SessionStore)，它使用 SHA512(而不是 session ID)生成 session 哈希值，并且所有这些都存储在 cookie 中，这意味着多个用户 ID 实际上可以具有相同的 session 哈希值，并且它可以正常工作。在我看来，这是一件非常危险的事情，用存储在服务器上的单个 key 公开大量哈希值，并使整个身份验证系统基于此 key 。现实世界中是否存在使用散列而不是存储服务器端 session ID 的大型应用程序？

2. 关于在服务器端存储事件 session ID 的主题，我还了解到您可以切换到使用不同类型的 Rails session 存储。基于此，我听说系统将身份验证系统作为服务移出并使用身份验证 token 。什么是身份验证 token 以及它与 session ID 有何不同？

3. 似乎我可以继续猜测一个随机字符串(对于哈希和服务器端 session )来获取现有 session 。有没有办法防止这种情况发生？使用 cookie 中存储的更多值是否正常？ (例如用户名、真实姓名甚至用于身份验证的另一个哈希值)

我知道我问了很多，但我相信这对于像我这样不了解身份验证的人很有用，并且对于为该主题打下坚实的基础非常有用。

Answer 1

I've read that by default starting from Rails 2, it now uses CookieStore (instead of SessionStore) which generates session hashes with SHA512 (instead of session ids), and all this is stored on a cookie which means multiple user id's can literally have the same session hash and it would just work fine. It seems to me that this is a very dangerous thing, exposing a large number of hashes with a single secret key stored on the server and basing your entire authentication system based on this key.

是的，乍一看似乎很可怕，但我不确定真正的危险是什么。在 Rails 4 中， session 数据使用 PBKBF2 进行加密，然后使用您的 session key 进行签名。此签名有助于检测加密 session 的内容是否已被篡改，如果服务器检测到篡改，将拒绝该 session 。

https://cowbell-labs.com/2013-04-10-decrypt-rails-4-session.html

如果有人获得了 session token (用于签署 session cookie)的访问权限，您可能会遇到比最终用户试图冒充错误用户更大的问题。

Is there a real world large scale application that uses hashing instead of storing server side session id's?

老实说，我暂时不知道这个问题的答案，但我怀疑这是 Rails 的“默认”这一事实意味着有不止少数网站使用 cookie session 存储。

On the topic of storing active session id's on server side, I've also read that you can switch to use different kinds of session storage for Rails. Based on this, I've heard of systems moving authentication systems out as services and using auth tokens instead. What's an auth token and how does it differ from a session id?

我现在在服务器上执行此操作 - 基本上，当用户进行身份验证时会生成一个随机哈希值，并且该哈希值会在 cookie 中存储、加密和签名。 cookie 哈希是服务器端数据存储的 key (在我的例子中是 Redis，但它可以位于关系数据库或内存缓存或任何您喜欢的数据库中)，而实际的 session 数据是映射到该 key 的存储的服务器端。这使得客户端掌握的 session 数据更少，人们可能会解密和分析它，因此通常更安全。

Seems like I can just keep guessing a random string (for both hashing and server side sessions) to grab an existing session. Is there a way to protect against this? Is it normal to use more values stored on a cookie? (such as the username, real name or even another hash for authentication)

是的，你可以这样做，但这需要非常非常长的时间。您还需要猜测如何对新被篡改的 cookie 数据进行签名，以便它与服务器期望在其端看到的内容相匹配，并且使用相当大的 key 进行签名。

我真的不认为除了使用 cookie 之外还有其他持久身份验证状态的选择(我想如果您感觉很陌生并且不太关心旧版浏览器支持，那么 HTML5 本地存储会起作用)。