security - 签名的 session cookie。一个好主意？

Question

为了提高性能，我考虑尝试消除普通的“ session cookie”，但加密 cookie 本身中的所有信息。

一个非常简单的例子:

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

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

该时间将用于最长到期时间，因此 cookie 不会永远存在。

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

使用 AES256 是否会更好？就我而言，数据不是保密的，但在任何情况下都不得更改。

编辑

经过一些良好的批评和评论后，我想添加以下内容:

• “ secret ”对于每个用户来说都是唯一的且不可预测(随机字符串 + 用户 ID？)
• Cookie 将自动过期(这是根据时间值 + 一定的秒数完成的)。
• 如果用户更改密码(或者甚至注销？)， secret 也应该更改。

最后一点:我正在尝试提出减少数据库负载的解决方案。这只是我正在研究的解决方案之一，但它是我最喜欢的。主要原因是我不必研究其他更适合此类数据的存储机制(memcache、nosql)，并且它使 Web 应用程序更加“无状态”。

10年后编辑

JWT 现在已经很流行了。

Answer 1

签名 token 对于您想要颁发 token 的任何情况来说都是一个很好的方法，然后在返回 token 时能够验证您是否颁发了 token ，而无需在服务器端存储任何数据。这对于以下功能很有用:

• 帐户登录有时间限制；
• 密码重置；
• 反 XSRF 形式；
• 限时表单提交(反垃圾邮件)。

它本身并不是 session cookie 的替代品，但如果它能够完全消除对任何 session 存储的需求，那可能是一件好事，即使性能差异不会很大。

HMAC 是生成签名 token 的一种合理方法。它不会是最快的；如果您了解并可以避免扩展攻击，您也许可以使用简单的哈希来逃脱。我会让你决定是否值得你冒这个险。

我假设您使用的任何语言中的 hmac() 都已设置为使用合适的服务器端 key ，没有它您就无法拥有安全的 key 签名的 token 。如果您要将整个身份验证系统建立在这个 secret 的基础上，那么这个 secret 必须是强大的并且受到良好的保护。如果您必须更改它，每个人都会被注销。

出于登录和密码重置的目的，您可能需要向 token 添加一个额外的因素，即密码生成编号。如果您愿意，您可以在数据库中重复使用散列密码的盐。这个想法是，当用户更改密码时，它应该使所有颁发的 token 失效(除了浏览器上执行密码更改的 cookie，该 cookie 会被重新颁发的 token 替换)。否则，用户发现自己的帐户已被盗用时无法将其他方拒之门外。