揭开 Web 身份验证的神秘面纱

Question

我目前正在研究我正在开发的网站的用户身份验证协议。我想创建一个身份验证 cookie，以便用户可以在页面之间保持登录状态。

这是我的第一个 bash：

cookie = user_id|expiry_date|HMAC(user_id|expiry_date, k)

k 是HMAC(user_id|expiry_date, sk)，sk 是只有服务器知道的 256 位密钥。 HMAC 是一个 SHA-256 哈希。请注意，“|”是一个分隔符，而不仅仅是串联。

这在 PHP 中是这样的：

$key = hash_hmac('sha256', $user_id . '|' . $expiry_time, SECRET_KEY);
$digest = hash_hmac('sha256', $user_id . '|' . $expiry_time, $key);
$cookie = $user_id . '|' . $expiry_time . '|' . $digest;

我可以看到它很容易受到安全 Cookie 协议中所述的重放攻击，但应该能够抵抗批量攻击和加密拼接。

问题：我在这里是正确的，还是我错过了一个巨大的漏洞？有没有办法防御使用动态分配的 IP 地址且不使用会话的重放攻击？

注意事项

我阅读的最新资料：
Web 上客户端身份验证的注意事项 又名傅等人。
(https://pdos.csail.mit.edu/papers/webauth:sec10.pdf)

安全的 Cookie 协议 又名刘等人。
(http://www.cse.msu.edu/~alexliu/publications/Cookie/cookie.pdf)
它扩展了以前的方法

强化的无状态会话 Cookie
(http://www.lightbluetouchpaper.org/2008/05/16/hardened-stateless-session-cookies/)
这也扩展了以前的方法。

由于这个主题非常复杂，我只是在寻找在创建和破坏身份验证方案方面具有实际经验的安全专家的答案。

Answer 1

一般来说这很好，我在多个应用程序中做了类似的事情。它不会比会话 ID 更容易受到重放攻击。您可以使用 SSL 保护令牌不被泄露以进行重放，就像您对会话 ID 所做的那样。

小建议：

• 在您的用户数据中放置一个字段，该字段会在更改密码时更新（可能是密码生成计数器，甚至只是随机盐），并将该字段包含在令牌和签名部分中。然后，当用户更改密码时，他们也会使任何其他被盗令牌无效。如果没有这个，您可以合理地允许令牌在到期前存活多长时间。

• 在令牌和签名部分中放置一个方案标识符，以便 (a) 您可以为不同目的使用不同类型的令牌（例如，一种用于身份验证，一种用于 XSRF 保护），以及 (b) 您可以使用新版本更新机制，而无需使所有旧令牌失效。

• 确保永远不会重复使用 user_id，以防止使用令牌来访问具有相同 ID 的不同资源。

• 管道分隔假定| 永远不会出现在任何字段值中。这可能适用于您（可能）处理的数值，但您可能在某些时候需要更复杂的格式，例如 URL 编码的名称/值对。

• 双 HMAC 似乎并没有真正让您受益。根据目前的理解，针对 HMAC-SHA256 的暴力破解和密码分析已经非常困难。

Answer 2

1. 除非您的交易/秒会对您的硬件造成负担，否则我只会在 cookie 中传递一个哈希值（即省略 user_id 和 expiry_date -- 给坏人提供比您绝对需要的更多信息是没有意义的） .

2. 鉴于之前的动态 IP 地址，您可以对下一个动态 IP 地址应该是什么做出一些假设（唉，我手头没有详细信息）。仅对动态 IP 地址中不变的部分进行散列将有助于验证用户，即使他们的 IP 地址发生更改。考虑到 IP 地址分配方案的多样性，这可能有效，也可能无效。

1234563足够的系统信息，您可能可以完全跳过使用（部分）IP 地址。这种技术需要一些实验。仅使用通常由浏览器提供的系统信息会更容易。

3. 您需要考虑您的 cookie 应该保持新鲜的时间。如果您可以忍受人们必须每天进行一次身份验证，那么您的系统身份验证编码会比允许人们每月仅进行一次身份验证（等等）更容易。

Answer 3

我认为这个协议非常弱！

1. 您的会话 cookie 不是具有高熵的随机源。
2. 服务器必须对每个页面进行非对称加密以验证用户。
3. 任何用户的安全性只依赖于服务器密钥 sk 的安全性。

服务器密钥 SK 是这里最容易受到攻击的部分。 如果有人可以猜到或窃取它，他可以作为特定用户登录。

因此，如果为每个会话和用户生成 sk，那么为什么要使用 hmac？ 我认为无论如何您都会使用 TLS，如果没有，请认为您的协议由于重放攻击和一般窃听而损坏！

如果为每个用户生成sk，而不是为每个会话生成sk，则类似于256位密码。

如果所有用户的 sk 都是相同的，那么某人只需破解 256 位，他就可以以任何他想要的用户身份登录。他只需要猜测 id 和到期日期。

看看digest-authentication。 这是由 rfc2617 指定的按请求身份验证。 使用随机数对每个请求发送的回报攻击是安全的。 使用散列进行窃听是安全的。 它集成在 HTTP 中。