会话和cookie如何在Rails中运行？

Question

我一直在使用Devise来处理我的Rails应用程序上的身份验证，但从来没有真正理解它是如何工作的。 因为Devise也使用Rails上的会话存储配置集，我假设这是一个关于使用Rails进行会话处理的问题。

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

这是我到目前为止所知道的......

我知道cookies和会话。 Cookie是存储在客户端的字符串，用于跨多个HTTP请求维护会话。

这是我对身份验证的基本理解（如果我错了，请纠正我）：

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

2. 在我们的数据存储上保存该会话ID后，我们返回一个响应，要求浏览器设置具有会话ID的cookie。 然后将该会话ID与用户ID一起发送，以便连续请求到域，直到它过期。 对于每个请求，我们的服务器将检查标头上的会话ID，并验证该会话ID是否对该用户标识有效。 如果是，则考虑用户进行身份验证。

这是我的问题：

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

2. 关于在服务器端存储活动会话ID的主题，我还读到您可以切换为Rails使用不同类型的会话存储。 基于此，我听说系统将身份验证系统作为服务移动并使用auth令牌代替。 什么是身份验证令牌，它与会话ID有什么不同？

3. 似乎我可以继续猜测一个随机字符串（用于散列和服务器端会话）来获取现有会话。 有没有办法防止这种情况发生？ 使用存储在cookie上的更多值是正常的吗？ （例如用户名，真实姓名或甚至用于身份验证的其他哈希）

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

Answer 1

我从默认情况下从Rails 2开始读到它，它现在使用CookieStore（而不是SessionStore），它使用SHA512（而不是会话ID）生成会话哈希，并且所有这些都存储在cookie中，这意味着多个用户ID可以真正拥有相同的会话哈希，它会正常工作。 在我看来，这是一个非常危险的事情，使用存储在服务器上的单个密钥暴露大量哈希，并基于此密钥基于整个身份验证系统。

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

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

如果有人获得了会话令牌（用于签署会话cookie）的访问权限，那么您手上的问题可能比最终用户冒充错误用户的问题要严重得多。

是否存在使用散列而不是存储服务器端会话ID的真实世界大规模应用程序？

老实说，我不知道这个问题的答案，但我怀疑这是Rails的“默认”这一事实意味着使用cookie会话商店的网站不止一些。

关于在服务器端存储活动会话ID的主题，我还读到您可以切换为Rails使用不同类型的会话存储。 基于此，我听说系统将身份验证系统作为服务移动并使用auth令牌代替。 什么是身份验证令牌，它与会话ID有什么不同？

我现在正在服务器上执行此操作 - 基本上，当用户进行身份验证时生成随机哈希，并在cookie中存储，加密和签名该哈希。 cookie哈希是服务器端数据存储区的密钥（在我的案例中是Redis，但它可以在关系数据库或内存缓存或任何你喜欢的内容中），实际的会话数据是映射到该密钥的存储服务器端。 这样，客户手中的会话数据就会减少，人们可能会对其进行解密和分析，因此通常会更安全一些。

似乎我可以继续猜测一个随机字符串（用于散列和服务器端会话）来获取现有会话。 有没有办法防止这种情况发生？ 使用存储在cookie上的更多值是正常的吗？ （例如用户名，真实姓名或甚至用于身份验证的其他哈希）

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

我真的认为没有太多选择来保持身份验证状态使用cookie（我想如果你感觉异国情调并且不关心遗留浏览器支持，那么HTML5本地存储会起作用）。