我知道如果将会话保存到 cookie,您需要使用秘密对其进行加密,否则恶意客户端可以随意修改其会话。由于许多普遍讨论的原因,这种设计仍然很糟糕。
但是,如果有人在服务器上保存会话(我碰巧通过 Rack:Session:Dalli 使用 Memcache 存储),我知道客户端获取的所有内容都是一个带有密钥的 cookie,服务器使用该密钥从存储中查找其会话。我仍然设置了会话秘密。但我不明白它的作用了。
我知道如果将会话保存到 cookie,您需要使用秘密对其进行加密,否则恶意客户端可以随意修改其会话。由于许多普遍讨论的原因,这种设计仍然很糟糕。
但是,如果有人在服务器上保存会话(我碰巧通过 Rack:Session:Dalli 使用 Memcache 存储),我知道客户端获取的所有内容都是一个带有密钥的 cookie,服务器使用该密钥从存储中查找其会话。我仍然设置了会话秘密。但我不明白它的作用了。
加密一个大的随机数本质上会产生另一个大的随机数。换句话说,如果信息没有任何意义(它只是一个随机数),那么加密就没有安全优势。如果您存储的 ID 中嵌入了一些信息,例如某个位集或仅使用了某个 ID 子集,则加密很有用。
会话 ID 的长度很重要。显然,ID 越长,越能抵抗暴力破解。同时用户会话的预期数量也是一个因素,因为会话数量减少了寻找有效会话 ID 所需的蛮力尝试次数。例如,两个同时进行的会话会将 ID 的有效强度降低一位(128 位密钥变得与 127 位密钥仅对一个会话有效)。一个拥有(比如说)1,000,000 个同时会话的亚马逊规模的网站实际上会丢失 20 位的会话密钥强度。
如果您需要防御暴力攻击,请实施一个中间件来检查它。向会话 ID 添加信息,例如应用程序唯一的字符串,可以更轻松地检测暴力攻击(并且需要会话 ID 加密)。请注意,这不会增强密钥本身的安全性,并且基本上是浪费精力,除非应用程序在显示不正确的会话 ID 时采取一些措施。
无论您做什么,只要确保使用 SSL 并将 cookie 设置为仅 https。会话服务器端超时,不要依赖 cookie 过期和客户端浏览器的善意。
TL;DR : 如果只使用 cookie 存储会话 ID,如果使用好的 RNG,则不需要加密。使用 SSL 并设置 cookie安全属性。