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

为了提高性能，我试图消除一个普通的“会话cookie”，但是加密了cookie本身的所有信息。签名会话cookie。一个好主意？

一个很简单的例子：

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

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

的时间将用于最大expirytime，所以饼干不会靠永远。

现在对于一个大问题：这是一个坏主意吗？

我最好用AES256代替吗？在我的情况下，数据不是保密的，但在任何情况下都不能改变。

编辑

一些好的批评和意见后，我想补充一点：

的“秘密”将是唯一的每个用户和不可预测的（随机字符串+用户名？）
Cookie将自动失效（这是基于时间值+一定的秒数完成的）。
如果用户更改密码（或者甚至注销？），秘密应该改变。

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

来源

2010-07-13 Evert

你的平台是什么？ – 2010-07-13 19:30:30

嗨米粉饼干，这是PHP，但我离开它，以避免特定于平台的讨论。目前我们在多个web服务器上使用PHP，并使用Master-Master mysql设置。会话cookie被缓存在memcached中。我们的瓶颈主要是附加和删除Cookie。复制还附加到辅助数据中心，并且会话相关查询是流量的一大块。 – Evert 2010-07-13 19:49:44

Evert，如果您用问题中概述的方法成功实施了整个客户端会话，我会感兴趣。您的实施细节是什么使您的系统尽可能安全？谢谢:) – 2011-07-11 08:42:25

一个签名令牌是什么，你要发出一个令牌，然后，返回时，能够确认您发布的令牌的好方法，而无需任何数据存储在服务器端。这对于以下功能很有用：

限时帐号登录;
password-resetting;
抗XSRF形式;
限时提交表格（反垃圾邮件）。

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

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

我假设您使用的任何语言的hmac()已被设置为使用合适的服务器端密钥，没有它，您不能拥有安全的签名令牌。如果您要将您的整个身份验证系统建立在此基础之上，则此秘密必须牢固且受到良好保护。如果你必须改变它，每个人都会被注销。

用于登录，您可能需要额外的因素添加到标识，密码生成编号密码重置的目的。如果你喜欢，你可以在数据库中重新使用哈希密码的盐。这个想法是，当用户更改密码时，它应该使任何已发出的令牌失效（除了浏览器上的cookie执行密码更改，它将被重新发布的cookie取代）。否则，发现其帐户的用户已被盗用不能锁定其他方。

来源

2010-07-13 18:54:33 bobince

添加世代号很有意义。谢谢！ – Evert 2010-07-13 18:58:35

读到这个似乎是个好主意;将Cookie标记为安全，设置到期时间，将其绑定到您网站的一个区域（例如，没有用户帐户更改命令）。还将用户代理字符串和IP地址散列到秘密中，以便cookie不会被盗用。请注意小于4k的cookie最大大小限制。有很多gotacha我认为它更聪明地寻找更快的serverside会话impl（riak，memcached），而不是冒着这个安全漏洞。 – simbo1905 2014-04-28 05:57:38

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

如果有东西必须是防篡改的，不要把它放在幼儿的手中。如同，即使使用防撬锁，也不要将其交给客户。

忽视意识形态问题，这看起来很不错。你没有随机数。你应该补充一点。只是随着用户标识和时间一起存储的一些随机垃圾，以防止重播或预测。

来源

2010-07-13 18:35:15 Borealid

目前我们的会话存储在主 - 主数据库中，由一系列Web服务器使用。尽管它是一个简单的BTREE，但我们希望减少占位面积。修剪会让io穿过屋顶。 – Evert 2010-07-13 18:55:03

@Evert这些表正确索引？你不应该看到“通过屋顶”的I/O。 – doug65536 2015-10-05 09:37:26

@DougGale：你正在回答很多很多年前的问题。 – Evert 2015-10-05 14:39:17

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

与每个会话使用加密随机数相比，此提议的会话处理程序更容易受到攻击。攻击场景如下。

很可能您在所有会话中对您的HMAC计算使用了相同的秘密。因此，这个秘密可能是攻击者用自己的帐户登录时所强制的暴力行为。通过查看他的会话ID，他可以获得除秘密以外的所有内容。然后攻击者可以暴力破解这个秘密，直到hmac值可以被复制。利用这个秘密，他可以重建一个管理cookie并改变他的user_id=1，这可能会授予他管理权限。

来源

2010-07-13 18:48:46 rook

该代码只是伪代码，我打算添加一个秘密，所以我现在做了。我非常了解我的平台的会话系统是如何工作的，这只是我正在处理数百万次会话，而且我需要认真思考。我很欣赏答案，但我是一名坐着的程序员。为什么你认为重新计算秘密是微不足道的。 Amazon AWS和OAuth大量使用它。 – Evert 2010-07-13 18:53:05

@Evert这是微不足道的秘密，秘密然后你需要攻击者蛮横这个价值。密码随机数**更安全**。 – rook 2010-07-13 19:00:27

没有试图听起来防守，我只是试图澄清我的情况。如果秘密将基于用户的ID和/或密码以及随机字符串，这难道不会使它变得相当困难吗？你是说没有办法可以做到这一点吗？ – Evert 2010-07-13 19:04:20

是的，这是一个坏主意。

对于初学者来说，这并不安全。通过这种方案，攻击者可以生成自己的cookie并冒充任何用户。

会话标识符应当从一个大的（128位）空间由密码随机数生成器来选择。

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

你有哪些性能问题？我从来没有见过一个Web应用程序，适当的安全性创造了任何类型的热点。

如果该频道没有隐私和完整性，那么您将面临中间人攻击。例如，没有隐私，Alice将她的密码发送给Bob。 Eve可以窥探它，并可以稍后以Alice身份登录。或者，部分完整性，Alice将她签名的cookie附加到购买请求并发送给Bob。 Eve截获请求并修改送货地址。 Bob验证cookie上的MAC，但无法检测到地址已被更改。

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

来源

2010-07-13 18:55:33 erickson

+1我完全同意。 – rook 2010-07-13 18:58:46

嗨埃里克森，黑客如何生成一个没有hmac随机数/ cookie的cookie？ – Evert 2010-07-13 18:59:19

@Evert我回答了这个问题。 – rook 2010-07-13 19:03:13

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

在努力提高性能，我想试图消除纯“会话cookie”，但在 cookie自身的加密所有的信息。

现在对于一个大问题：这是一个坏主意吗？

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

长的答案是：这取决于您的实施。会话很棒，速度很快，很简单，而且很安全。然而，作为一个无国籍的系统运行良好，部署需要多一点参与，可能超出小型项目的范围。

实现基于令牌（饼干）的认证系统现在是非常普遍，工作得非常好，为stateless系统/ API的。这使得使用单个账户对许多不同的应用程序进行身份验证成为可能。即。使用Facebook/Google登录{无关联网站}。

像这样实施oAuth系统本身就是一个大问题。所以我会留下一些文档oAuth2 Docs。我也建议看看Json Web Tokens (JWT)。

额外

最后要注意：我试图拿出解决方案来降低数据库负载。这只是我正在调查的解决方案之一

Redis对于卸载数据库查询很有效。 Redis是一款内存简单的存储系统。非常快速的〜临时存储可以帮助减少数据库命中。

来源

2017-06-01 14:52:46

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

回答

相关问题