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

Question

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

一个非常简单的例子：

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

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

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

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

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

修改

经过一些好的批评和评论后，我想补充一点：

• '秘密'是每用户唯一且不可预测的（随机字符串+用户ID？）
• Cookie会自动过期（这是根据时间值+一定的秒数完成的。）
• 如果用户更改了密码，（或者甚至可能会注销？），秘密应该更改。

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

10年后编辑

JWT现在已成为一件事。

Answer 1

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

• 时间限制的帐户登录;
• 密码复位;
• 反XSRF表格;
• 时间限制表单提交（反垃圾邮件）。

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

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

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

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

Answer 2

是的，这是一个坏主意。

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

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

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

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

---

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

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

Answer 3

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

  

为了提高性能，我正在考虑尝试   消除一个简单的“会话cookie”，但加密所有信息   饼干本身。

     

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

简短的回答是： 不，这不是一个坏主意，事实上这是一个非常好的主意，已成为行业标准。

答案很长：这取决于您的实施。会话很棒，速度很快，很简单，而且很容易保护。然而，无状态系统运行良好的情况下，部署更多，可能超出了较小项目的范围。

实施基于令牌（Cookie）的身份验证系统现在非常普遍，对于无状态系统/ apis 非常有效。这使得可以使用单个帐户对许多不同的应用程序进行身份验证。即。使用Facebook / Google登录{unaffiliated site}。

实现像这样的oAuth系统本身就是一个很大的主题。所以我会给你留下一些文件oAuth2 Docs。我还建议调查Json Web Tokens (JWT)。

<强>额外

  

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

Redis适用于卸载数据库查询。 Redis是一种内存简单的存储系统。非常快，〜临时存储，可以帮助减少数据库命中。

Answer 4

是什么让您认为这会提高性能与安全会话ID以及从会话的服务器端组件检索用户ID和时间信息？

如果必须防止篡改，请不要将其放在幼儿的手中。同样，即使使用防篡改锁定，也不要将它交给客户端。

忽略意识形态问题，这看起来相当不错。你没有nonce。你应该添加它。只是随着用户ID和时间存储的一些随机垃圾，以防止重放或预测。

Answer 5

你不应该重新发明轮子。您的开发平台附带的会话处理程序更安全，更容易实现。 Cookie应始终是非常大的随机数，链接到服务器端数据。包含用户ID和时间戳的cookie无助于强化会话免受攻击。

这个提议的会话处理程序比每个会话使用加密nonce更容易受到攻击。攻击场景如下。

对于所有会话，您可能使用相同的密钥进行HMAC计算。因此，这个秘密可能是由攻击者用他自己的帐户登录强制执行的。通过查看他的会话ID，他可以获得除秘密之外的所有内容。然后攻击者可以强制破坏秘密，直到可以再现hmac值。使用这个秘密，他可以重建一个管理cookie并更改他的user_id=1，这可能会授予他管理访问权限。