我对您对此安全问题的建议/意见感兴趣。
我在考虑做这样的事情：
你怎么看？这个可以吗？ 我还可以使用$ _SERVER ['HTTP_USER_AGENT']检查实现什么，以确保cookie没有被盗（IP地址除外）？
P.S。来自敏感数据的cookie只包含userId。
修改 好的，清除一些事情。 我正在尝试制作不依赖于会话的“安全”auth系统。有问题的应用程序或多或少构建为纯粹的restful api。
第2步：
问题： “Fu的协议没有提供答案 题。 Fu的原型只涉及一个关键 col，即服务器密钥。一个简单的解决方案 - 是使用此服务器密钥加密数据字段 每个饼干;但是，这个解决方案并不安全。“
解决方案： “我们解决这个问题的方法简单而有效。 我们建议使用HMAC（用户名|到期时间， sk）作为加密密钥。这个解决方案有以下几点 降低了三个好的属性。首先，加密密钥 由于用户的原因，每个不同的cookie都是唯一的 名称和到期时间。请注意，每当一个新的 创建cookie，新的到期时间包括在内 饼干。其次，加密密钥是不可伪造的 因为服务器密钥是保密的。三，加密 - 每个cookie的密钥不需要任何存储 服务器端或cookie内，而不是 动态地服务器。 “ 来自Alex X. Liu的论文“安全的Cookie协议”，Jason M. Kovacs
第4步： 加密数据（看起来像这样：'marko@example.com|34234324234|324erfkh42fx34gc4fgcc423g4'），这样即使客户也无法准确知道里面是什么。
第5步： Base64编码只是为了使最终值漂亮。
答案 0 :(得分：10)
我会咬人。
为了保持任何相似的状态，您需要使用某种类型的键来识别用户。该密钥作为cookie或通过查询字符串参数发送到浏览器。
现在，该密钥的验证可以在Web服务器本身（会话）内部进行，也可以通过检查其他存储机制（通常是数据库记录）来进行。
密钥本身应该使用某种机制进行混淆。混淆的原因仅仅是如果原始用户或其他人决定检查该值，则更难以猜测其他密钥可能具有的值。例如，如果密钥是您的用户ID（不推荐）并且您正在使用递增的int，则猜测其他用户密钥是微不足道的。 我想强调，对密钥进行模糊处理（甚至是彻底加密）绝对不会对被劫持的会话提供保护。它所做的只是让其他会话密钥更难猜测 。
那就是说，我相信密钥应该与你的用户ID没有任何关系，而是像生成的GUID那样是一些其他接近随机的值。坦率地说，基本64编码的GUID与加密用户ID +时间完全相同。只是一个在服务器上的计算密集程度高于另一个。
当然，这个密钥可能会根据每个请求而改变。浏览器发布了一些内容，您生成一个新密钥并将其发回。如果浏览器发布了过期密钥，则将其记录下来并将其踢回登录屏幕。这应该在一定程度上防止重放攻击。但是，它引入了其他挑战，例如在各种浏览器上使用“后退”按钮。所以，你可能不想走这条路。
那表示您不能依赖客户端IP地址，因为同一用户可能使用不同的IP发送跟进请求。您不能依赖浏览器指纹识别，因为任何体面的黑客工具都会捕获它并提交相同的值，无论它们使用什么。
现在，如果你真的想要这样做，你应该启用SSL。否则你就是在浪费时间。整个会话（从登录屏幕开始）需要加密。如果不是那么有人可以简单地听取该cookie，立即重播并劫持会话。重点是他们不需要知道其中包含的值来使用它们。所以你所拥有的所有散列等都只会增加你的服务器负载。
我说过使用SSL吗？ ;）这将加密来自对话开始的流量，并且攻击者无法重放相同的数据包，因为他们必须与服务器协商自己的握手。这意味着您所要做的就是确保您使用的任何会话ID都是不可猜测的，这样一个登录用户就无法接管另一个会话。
所以，总结一下：你发布的方法是浪费时间。
最好只获得10美元的SSL证书并使用base 64编码的GUID作为会话ID。如何在服务器上存储该会话信息并不重要......除了负载均衡的情况。此时它需要在进程外并由数据库服务器支持..但这是另一个问题。
答案 1 :(得分：1)
@Marko关于这种“cookie中的会话”方法的安全性的一些评论是：
首先，正如其他人所说，你需要一个安全的连接。围绕这一要求没有可行的方法。这是必须的。
除此之外，实施安全加密/认证系统还有很多陷阱。例如，您需要将MAC验证设置为“恒定时间”，您需要注意如何实现加密/验证（操作模式，IV创建等）。等等。
如果你不确定这些问题，我建议你看看TCrypto（我维护）：
这是一个小型的PHP 5.3+键值存储库（默认情况下，cookie将用作存储后端）。专为（可扩展）“cookie中的会话”使用而设计。随意使用它:)另外，如果您对低级实现感兴趣，请查看代码。代码库不是那么大，我想它会做得很好，在PHP应用程序中演示与加密相关的代码使用。