验证没有会话的系统

 

我对你对这个安全问题的建议/意见很感兴趣。

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

  • 从userId + expirationTime构建的字符串获取哈希MAC（sha256），并将其作为从某个秘密字符串和$ _SERVER ['HTTP_USER_AGENT']构建的密钥字符串。
  • 从userId + expirationTime获取哈希MAC（sha256），并将其作为以前制作哈希的密钥（来自步骤1）。
  • 从userId | expiration |构建字符串 和以前做的散列（从步骤2）。
  • 用'rijndael-256'算法加密给定的字符串（来自步骤3）。 （mcrypt函数族）。
  • 编码到base64。
  • 用给定的值设置cookie。

    • 你怎么看。 这个可以吗？ 我还可以使用$ _SERVER ['HTTP_USER_AGENT']检查来实现，以确保cookie不被盗（IP地址除外）？

    PS根据敏感数据，cookie将只包含userId。

    编辑：好的，以清除一些事情。 我正在尝试使不依赖会话的“安全”身份验证系统。 有问题的应用程序或多或少地构建为纯粹的平静API。

    第2步：

    问题： “Fu的协议没有提供这个问题的答案，Fu的协议只涉及一个密钥，即服务器密钥，一个简单的解决方案是使用这个服务器密钥来加密每个cookie的数据字段;但是，这种解决方案并不安全。“

    解决方案： “我们的解决方案简单高效，我们建议使用HMAC（用户名|过期时间，sk）作为加密密钥，该解决方案具有以下三个优点：首先，加密密钥是唯一的对于每个不同的cookie，由于用户名和过期时间的关系，请注意，无论何时创建一个新的cookie，cookie中都会包含一个新的过期时间;其次，加密密钥是不可伪造的，因为服务器密钥是保密的。每个cookie的加密密钥不需要服务器端或cookie内的任何存储，相反，它是由服务器动态计算的。“来自Alex X. Liu1，Jason M的论文”安全Cookie协议“ Kovacs

    步骤4：加密数据（看起来像这样：'marko@example.com|34234324234|324erfkh42fx34gc4fgcc423g4'），这样即使客户端也不知道里面的内容。

    第5步： Base64编码只是为了让最终值变得漂亮。

    我会咬。

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

    现在，该密钥的验证可以发生在Web服务器本身（会话）内，或者通过检查其他存储机制（通常是数据库记录）。

    密钥本身应该使用某种机制进行混淆。 混淆的原因只是为了更难猜测原始用户或其他人决定检查该值时其他键可能具有的值。 例如，如果密钥是您的用户标识（不推荐），并且您正在使用增量整数，那么猜测其他用户密钥就很简单。 我想强调的是，对密钥进行混淆（甚至是彻头彻尾的加密）绝对不能保护被劫持的会话。 它所做的只是让猜测其他人的会话密钥变得更加困难 。

    也就是说，我相信这个关键应该与你的用户id完全没有关系，而应该像生成的GUID那样具有其他几乎随机的值。 坦率地说，64位编码的基本GUID与加密用户ID +时间具有完全相同的安全级别。 它只是一个在你的服务器上比另一个在计算上更密集。

    当然，这个密钥可以在每次请求时改变。 浏览器发布一些内容，您会生成一个新密钥并将其发回。 如果浏览器张贴过期的密钥，然后登录并将其踢回登录屏幕。 这应该防止重播攻击..在一定程度上。 但是，它引入了其他挑战，例如在各种浏览器上使用“后退”按钮。 所以，你可能不想走这条路。

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

    现在，如果你真的想这样做，你应该打开SSL。 否则，你会浪费你的时间。 整个对话（从登录屏幕开始）需要加密。 如果不是，那么有人可以简单地听取该cookie，立即重播并劫持会话。 要点是他们不需要知道其中包含的值来使用它们。 所以，所有的哈希等，你只是蓬松，这会增加你的服务器负载。

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

    所以，总结一下：你发布的方法是浪费时间。

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

    @Marko关于这种“cookie中的会话”方法有多安全的一些评论是：

    首先，正如其他人所说，你需要一个安全的连接。 这个要求没有可靠的方法。 这是必须的。

    除此之外，实现安全的加密/认证系统还有很多缺陷。 例如，您需要将MAC验证设置为“恒定时间”，您需要注意如何实施加密/验证（操作模式，IV创建等）。 等等。

    如果你不确定这些问题，我建议你看看TCrypto（我维护）：

    TCrypto

    它是一个小型PHP 5.3+键值存储库（默认情况下Cookie将用作存储后端）。 精确设计（可缩放）“cookie中的会话”用法。 随意使用它:)另外，如果您对低级实现感兴趣，请查看代码。 代码库不是那么庞大，我想它会做得很好，证明PHP应用程序中与加密相关的代码使用情况。

    链接地址: http://www.djcxy.com/p/23659.html

    上一篇: Authenticate system without sessions

    下一篇: Switching between HTTP and HTTPS pages with secure session