4

我有一个用户帐户“会员中心”，它显示了客户在我公司的所有订阅和会员资格。这是在https://secure.example1.com/membercenter/。

我有另一个网站，它是实际的会员网站。这是在http://www.example2.com/。（每个站点在不同的域上，尽管它是同一个专用服务器。

我想提供对会员网站的轻松登录，而不在链接中包含用户的用户名和密码。

所以我想出的是：

当用户单击其成员资格的“登录”链接时，我创建了他们的用户 ID + unix 时间戳的 md5 哈希，并将其与他们的用户 ID 和时间戳一起添加到数据库表中。

然后我重定向到http://www.example2.com/login?hash= （哈希）。

example2 上的登录脚本获取哈希并在同一个表中查找它。如果散列存在，我会使用与散列一起存储的用户 ID 从客户数据库中检索他们的用户名和密码，并将其传递给站点预先存在的登录函数，然后他们就可以登录了。

当这个哈希登录脚本运行时，它首先删除任何超过 5 分钟的行，然后检查传递的哈希值。如果找到散列，则将用户登录，然后从表中删除使用的散列。这意味着表中永远不会有任何哈希值超过 5 分钟。唯一会（应该）在表中留下任何哈希值的情况是，如果用户在单击链接后以某种方式无法将其从 secure.example1.com 变为 www.example2.com（例如，互联网在右侧出现故障）第二，DNS 问题解决 example2.com 等）。5 分钟到期意味着他们可以坐在那里重新加载重定向的 URL，直到他们进入，或者直到 5 分钟过去。

当用户被重定向时，他们确实看到了哈希值。

每次从 secure.example2.com 中单击登录链接时，都会计算并存储一个新的哈希值。

我的问题是......我错过了一些明显的东西吗？你将如何破解或破解它？我是否只是在我的站点中创建了一个巨大的安全漏洞？

非常感谢蜂巢思维！

编辑：这是对进入 www.example2.com 并使用您的用户名/密码使用表单登录的正常模式的补充。

EDIT2：对 tobyhede 的回应：嗅探哈希。攻击者还必须阻止用户访问 www.example2.com 上的登录脚本，因为哈希一旦使用就会被删除。如果他们能够阻止这种情况，他们还必须在五分钟内使用哈希，否则它将被自动删除。

EDIT3：回复：攻击者生成自己的哈希：黑客必须将这些哈希插入数据库并包含有效的用户 ID（没有用户知道他们的用户 ID）。他们会怎么做？由于哈希只使用一次，然后立即删除，我不相信以下任何攻击都会起作用。

4

4 回答 4

3

有人需要做的就是拦截带有哈希的 URL，他们就可以访问您的系统。您确实应该使用 HTTP POST 通过 SSL 传递哈希。

于 2008-10-23T05:22:05.660 回答
2

虽然你不能让这种方案完全无懈可击，但有很多事情可以改进它：

  • 生成密钥时使用随机种子而不是 unix 时间戳
  • 检查第二页请求中的referer是否是第一页
  • 检查两个请求的来源是否相同

加密知识证明方案可能适用于这种情况，以最安全的方式解决问题。今天早上开会后，我的大脑有点太糊涂了，但无法说出它们的适用性：）

于 2008-10-23T10:04:01.503 回答
0

您在哈希中使用的 id 和用户用于登录站点的用户 id 是否不同？在通过生成哈希来攻击您的系统时，这是至关重要的部分。要考虑的另一件事是，您使用的 ID 是否易于猜测，例如数字或单词？

你必须想出一个解决方案，其中包含攻击者不容易猜到的东西。基本上你想在你的散列中有一个秘密，攻击者几乎不可能猜到。这就是为什么在你的哈希中使用盐（随机位）是要走的路。

我想您知道针对MD5和SHA-1哈希的攻击吗？在 MD5 中，实际上存在哈希冲突的可能性（http://merlot.usc.edu/csac-s06/papers/Wang05a.pdf），因为 SHA-1 被认为仍然是安全的，但也存在针对两者的彩虹表攻击哈希。

使用盐、用户 ID 和时间戳生成哈希听起来对您的解决方案是可行的。我还建议您在使用后删除哈希。

于 2008-10-24T14:12:35.013 回答
0

如果攻击者知道用户即将登录，则攻击者可以生成哈希（或一系列时间戳略有不同的哈希）并在用户登录之前登录。更好的解决方案是用随机生成的令牌替换散列。然后攻击者将不得不拦截用户对站点 example2 的登录请求。

只要您在站点 example2 上使用 HTTP 而不是 HTTPS，任何方案都不会是安全的。例如，假设您为站点 example2 找到了安全的完美登录方案。但是，在登录之后，来自用户的请求将在 URL 或请求标头（例如 cookie）中发送会话信息。这些请求可以被拦截，攻击者可以窃取会话信息。在攻击者最坏的情况下，您会将会话链接到他们的源 IP，并且攻击者需要伪造源 IP。

于 2008-10-23T09:23:40.523 回答