签名会话cookie.一个好主意？

为了提高性能,我想要尝试消除一个简单的"会话cookie",但加密cookie本身的所有信息.

一个非常简单的例子:

userid= 12345
time=now()
signature = hmac('SHA1',userid + ":" + time, secret);

cookie = userid + ':' + time + ':' + signature;

时间将用于最长的到期时间,因此cookie不会永久存在.

现在提出一个大问题:这是一个坏主意吗？

我最好使用AES256吗？在我的情况下,数据不是保密的,但在任何情况下都不得更改.

编辑

经过一些好的评论和评论,我想补充一下:

'秘密'是每用户唯一且不可预测的(随机字符串+用户ID？)

cookie将自动过期(这是基于时间值+一定的秒数完成的).

如果用户更改了密码(或者甚至可能会注销？),秘密应该会改变.

最后一点:我正在尝试提出减少数据库负载的解决方案.这只是我正在研究的解决方案之一,但这是我的最爱.主要原因是我没有必要考虑更适合这种数据的其他存储机制(memcache,nosql),它使Web应用程序更加"无状态".

1> bobince..：

---

对于要发出令牌的任何内容,签名令牌都是一种很好的方法,然后在返回时,能够验证您是否已发出令牌,而无需在服务器端存储任何数据.这适用于以下功能:

时间限制的帐户登录;

密码重置;

反XSRF形式;

限时提交表格(反垃圾邮件).

它本身并不是会话cookie的替代品,但如果它可以消除对任何会话存储的需求,那可能是一件好事,即使性能差异不会很大.

HMAC是生成签名令牌的一种合理方式.它不会是最快的; 如果你知道并且可以避免扩展攻击,你可以使用简单的哈希.我会让你决定这是否值得为你冒险.

我假设hmac()您使用的任何语言都设置为使用合适的服务器端密钥,否则您将无法拥有安全的签名令牌.如果您要围绕整个身份验证系统,这个秘密必须是强大且受到良好保护的.如果你必须改变它,每个人都会被注销.

对于登录和密码重置目的,您可能需要为令牌添加额外的因子,即密码生成号.如果您愿意,可以在数据库中重复使用散列密码的salt.这个想法是,当用户更改密码时,它应该使任何已发布的令牌无效(除了浏览器上执行密码更改的cookie,它将被重新发布的密码替换).否则,发现其帐户遭到入侵的用户无法锁定其他方.

2> erickson..：

---

是的,这是一个坏主意.

对于初学者来说,它并不安全.使用此方案,攻击者可以生成自己的cookie并模拟任何用户.

会话标识符应由加密随机数生成器从大(128位)空间中选择.

它们应该保密,以便攻击者无法窃取它们并模仿经过身份验证的用户.执行需要授权的操作的任何请求都应该是防篡改的.也就是说,整个请求必须具有某种完整性保护,例如HMAC,以便其内容不能被改变.对于Web应用程序,这些要求不可避免地导致HTTPS.

您有什么性能问题？我从来没有见过适当的安全性创建任何类型的热点的Web应用程序.

---

如果频道没有隐私和完整性,那么你可以让自己受到中间人攻击.例如,没有隐私,Alice将她的密码发送给Bob.Eve窥探它,可以稍后以Alice身份登录.或者,在部分完整性的情况下,Alice将其签名的cookie附加到购买请求并将其发送给Bob.Eve拦截请求并修改送货地址.Bob验证cookie上的MAC,但无法检测到地址已被更改.

我没有任何数字,但在我看来,中间人攻击的机会在不断增长.我注意到餐馆使用Wi-Fi网络,他们为客户提供信用卡处理服务.如果他们的流量不是通过HTTPS,那么图书馆和工作场所的人们往往容易被嗅探.

---

嗨Erickson,黑客如何在没有hmac nonce/secret的情况下生成cookie？

3> 小智..：

---

我知道这个问题现在已经很老了，但是我认为用最新的回答来更新答案可能是个好主意。对于像我这样可能会偶然发现的人。

为了提高性能，我正在考虑尝试消除普通的“会话cookie”，而是对cookie本身中的所有信息进行加密。

现在有个大问题：这是个坏主意吗？

简短的答案是：不，这不是一个坏主意，实际上，这是一个非常好的主意，并且已经成为行业标准。

长答案是：这取决于您的实现。会话很棒，速度很快，很简单，而且很容易保证安全。但是，在无状态系统运行良好的地方，部署会涉及更多的工作，并且可能不在较小项目的范围之内。

现在，基于令牌（cookies）的身份验证系统的实现非常普遍，并且对于无状态系统/ api来说非常有效。这样就可以通过一个帐户对许多不同的应用程序进行身份验证。即。使用Facebook / Google登录到{unaffiliated site}。

实现这样的oAuth系统本身就是BIG主题。因此，我将为您提供一些oAuth2 Docs文档。我还建议研究Json Web令牌（JWT）。

额外

最后一点：我正在尝试提出减少数据库负载的解决方案。这只是我正在研究的解决方案之一

Redis可以很好地减轻数据库查询的负担。Redis是一个内存中简单的存储系统。〜临时存储，非常快，可以帮助减少数据库命中率。