php - 在没有 session 的情况下验证系统 - 只有 cookie - 这是否相当安全？

Question

我很想知道你对这个安全问题的建议/意见。

我正在考虑做这样的事情:

1. 从由 userId + expirationTime 构建的字符串中获取哈希 MAC (sha256)，并作为由一些 secret 字符串和 $_SERVER['HTTP_USER_AGENT'] 构建的 secret key 字符串。
2. 从 userId + expirationTime 获取哈希 MAC (sha256)，并将其作为之前生成的哈希(来自第 1 步)的 key 。
3. 从 userId|expiration| 构建字符串和之前制作的散列(来自第 2 步)。
4. 使用“rijndael-256”算法加密给定字符串(来自第 3 步)。 (mcrypt 系列函数)。
5. 编码为 base64。
6. 设置给定值的 cookie。

你怎么看。这个可以吗？我还能用 $_SERVER['HTTP_USER_AGENT'] 检查实现什么，以确保 cookie 没有被盗(IP 地址除外)？

附言来自敏感数据的 cookie 将仅包含 userId。

编辑:确定清除一些东西。我正在尝试制作不依赖于 session 的“安全”身份验证系统。有问题的应用程序或多或少地构建为纯 restful api。

第 2 步:

问题:“傅的协议(protocol)没有对此提供答案题。 Fu 的原型(prototype)中只有一把 key ——col，即服务器 key 。一个简单的解决方案-tion 是使用此服务器 key 来加密数据字段每个cookie；但是，此解决方案并不安全。”

解决方案:“我们对这个问题的解决方案简单而有效。我们建议使用HMAC(用户名|过期时间,sk) 作为加密 key 。该解决方案具有以下降低三个良好的性能。一、加密 key 由于用户的原因，每个不同的 cookie 都是唯一的名称和到期时间。请注意，每当一个新的cookie被创建，一个新的过期时间被包含在 cookies 。二、加密 key 不可伪造因为服务器 key 是保密的。三、加密——每个 cookie 的 key 不需要任何存储服务器端或 cookie 中，而是 com-由服务器动态放置。“摘自 Alex X. Liu1 和 Jason M. Kovacs 的论文“A Secure Cookie Protocol”

第 4 步:加密数据(看起来像这样:'marko@example.com|34234324234|324erfkh42fx34gc4fgcc423g4')，这样即使客户端也无法确切知道里面有什么。

第 5 步:Base64 编码只是为了使最终值更漂亮。

Answer 1

我会咬人的。

为了保持任何状态，您需要使用某种类型的 key 来识别用户。该 key 作为 cookie 或通过查询字符串参数发送到浏览器。

现在，可以在 Web 服务器本身( session )内部或通过检查其他一些存储机制(通常是数据库记录)来验证该 key 。

key 本身应该使用某种机制进行混淆。混淆的原因很简单，如果原始用户或其他人决定检查值，则更难猜测其他键可能具有的值。例如，如果 key 是您的用户 ID(不推荐)并且您使用的是递增整数，那么猜测其他用户 key 是微不足道的。 我想强调的是，混淆(甚至完全加密) key 绝对不能防止被劫持的 session 。它所做的只是让猜测其他人的 session key 变得更加困难。

也就是说，我认为 key 应该与您的用户 ID 完全无关，而应该是其他一些接近随机的值，例如生成的 GUID。坦率地说，base 64 编码的 GUID 与加密用户 ID + 时间处于完全相同的安全级别。只是其中一个在您的服务器上比另一个计算密集度更高。

当然，这个 key 可以根据每个请求而改变。浏览器发布一些东西，你生成一个新 key 并将其发回。如果浏览器发布过时的 key ，则将其记录下来并将其踢回登录屏幕。这应该在一定程度上防止重放攻击。但是，它引入了其他挑战，例如在各种浏览器上使用后退按钮。所以，您可能不想走这条路。

也就是说，您不能依赖客户端 IP 地址，因为同一用户可能会使用不同的 IP 发送后续请求。您不能依赖浏览器指纹识别，因为任何体面的黑客工具都会捕获它并提交相同的值，无论它们使用什么。

现在，如果你真的想正确地做到这一点，你应该打开 SSL。否则你就是在浪费时间。整个对话(从登录屏幕开始)都需要加密。如果不是，那么有人可以简单地监听该 cookie，立即重放它并劫持 session 。重点是他们不需要知道其中包含的值就可以使用它们。因此，您拥有的所有这些散列等都只是绒毛，会增加您的服务器负载。

我有说使用 SSL 吗？ ;) 这将从对话开始加密流量，攻击者无法重播相同的数据包，因为他们必须与服务器协商自己的握手。这意味着您所要做的就是确保您使用的任何 session ID 都是不可猜测的，这样一个登录用户就无法接管另一个 session 。

---

因此，总结一下:您发布的方法是在浪费时间。

您最好只获得 10 美元的 SSL 证书并使用 base 64 编码的 GUID 作为 session ID。如何在服务器上存储该 session 信息并不重要......除非在负载平衡的情况下。在这一点上，它需要在进程外并由数据库服务器支持。但这是另一个问题。