基本上,我是一个新手.我已经阅读了一些关于身份验证的文章,但大多数都涉及抽象的库(他们谈论引擎,中间件等)对我来说没有多大意义.我真的在寻找较低级别的细节.
这是我目前所知道的……
我知道cookie和会话. Cookie是存储在客户端的字符串,用于跨多个HTTP请求维护会话.
这是我对身份验证的基本理解(如果我错了,请纠正我)：
>当用户登录时,我们将SSL加密的请求发送到服务器.如果凭证有效,我们会在数据库(或任何其他数据存储)上保存一个名为session id的随机字符串作为与用户ID关联的有效会话ID.此会话ID会针对用户的每次登录/注销而更改.
>在我们的数据存储中保存该会话ID后,我们返回一个响应,要求浏览器设置具有会话ID的cookie.然后,将发送此会话ID以及用户ID,以便连续请求到域,直到它过期.对于每个请求,我们的服务器将检查标头上的会话ID,并验证该会话标识是否对该用户标识有效.如果是,则考虑用户进行身份验证.
这是我的问题：
>我已经从Rails 2开始默认读取它现在使用CookieStore(而不是SessionStore),它使用SHA512(而不是会话ID)生成会话哈希,并且所有这些都存储在cookie中,这意味着多个用户ID可以字面意思有相同的会话哈希,它会工作正常.在我看来,这是一个非常危险的事情,使用存储在服务器上的单个密钥暴露大量哈希,并基于此密钥基于整个身份验证系统.是否存在使用散列而不是存储服务器端会话ID的真实世界大规模应用程序？
>关于在服务器端存储活动会话ID的主题,我还读到您可以切换为Rails使用不同类型的会话存储.基于此,我听说系统将身份验证系统作为服务移动并使用auth令牌代替.什么是身份验证令牌,它与会话ID有什么不同？
>似乎我可以继续猜测一个随机字符串(用于散列和服务器端会话)来获取现有会话.有没有办法防止这种情况？使用存储在cookie上的更多值是正常的吗？ (例如用户名,真实姓名甚至是另一个用于身份验证的哈希)
我知道我问了很多,但我相信这对于像我这样不了解身份验证的人会很有用,并且对于获得有关该主题的坚实基础非常有用.
解决方法
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中,会话数据使用PBKBF2加密,然后使用您的会话密钥进行签名.此签名有助于检测加密会话的内容是否已被篡改,如果检测到篡改,服务器将拒绝该会话.
https://cowbell-labs.com/2013-04-10-decrypt-rails-4-session.html
如果某人获得了会话令牌(用于签署会话cookie)的访问权限,那么您手上的问题可能比最终用户试图冒充错误用户的问题要严重得多.
Is there a real world large scale application that uses hashing
instead of storing server side session id’s?
老实说,我不知道这个问题的答案,但我怀疑这是Rails的“默认”这一事实意味着使用cookie会话商店的网站不止一些.
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哈希是服务器端数据存储区的密钥(在我的案例中是Redis,但它可以在关系数据库或内存缓存或任何你喜欢的内容中),实际的会话数据是映射到该密钥的存储服务器端.如果人们可以解密和分析它,那么客户端手中的会话数据就会减少,因此通常会更安全一些.
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数据进行签名,以使其与服务器期望看到的内容相匹配,并使用相当大的密钥进行签名.
我真的认为没有太多选择来保持身份验证状态使用cookie(我想如果你感觉异国情调并且不关心遗留浏览器支持,那么HTML5本地存储会起作用).