security - 散列以创建唯一的 URL，因此很难猜测有效的 URL 来代替身份验证

Question

我正在考虑编写一个网页，为客户提供反馈表。
我希望客户能够使用任何特定订单的唯一 URL 访问此表单；一个简单的例子是 http://www.example.com/feedback/012345 的格式.

旁注:我已经熟悉 URL 重写。在给定语言或给定服务器上创建/重定向 URL 不在此问题的范围内

客户必须进行身份验证是 Not Acceptable (或者，就此而言，甚至拥有一个帐户)以访问反馈表。但是，出于对统计正确性的考虑，我对 example.com/feedback/[order_id] 上面的明显解决方案并不满意。这允许任何人更改 URL 中的 ID 并访问另一个订单的反馈。

另一方面，我希望这些 URL 能够从收据等打印输出中输入，因此 在许多“重置密码”链接上提供长哈希不是有效选项 .

基于此，我有以下标准:

每个订单都应该有一个唯一的 URL

这个 URL 应该是相对人类可输入的，现在把它理解为“短”

应该不可能更改 URL 中的字符并访问其他订单(在合理的概率范围内)

我的想法是我应该在 URL 中放入两条数据。客户记录上有很多人类可读的数据可以帮助解决这个问题，例如客户 ID、订单的联系电话号码、姓氏……虽然这消除了更改一两位数字的能力，但我没有看到它显着提高了无聊攻击者对给定 URL 的“可猜测性”。

以/feedback/[surname]/[id] 为例，您可以通过简单的字典攻击页面来接收一组有效的 URL:

for x in range(00000,99999):
    for name in ["jones","smith", ....]:
        url = "http://www.example.com/feedback/"+name+"/"+x
        if exists(url):
            print(url)

考虑到像 tinyurl 这样的服务，我考虑的下一件事是散列 ID 号并以/feedback/[hash]/[id] 的形式提供 URL
从那以后，我做了一些研究并了解到 URL 缩短服务实际上可能使用自动增量 ID 记录而不是实际的数学哈希。这个方法可能没用

如果使用实际散列函数， 重要的是散列显然不是来自 ID 号 .提供像/feedback/trpxq/53192 这样的 URL 是没有用的，因为在看到其中的一两个之后，您可以轻松地提取之前的记录:/feedback/trpxp/53191

当时我在想，如果散列包含一个盐可能会有所帮助，这样即使知道使用了什么散列函数，也不可能对任何旧的有效订单 ID 进行散列并调出有效的 URL。

所以，最后，这是实际的问题:

什么函数最适合基于 7-10 位整数 ID 和任意盐来创建一个简短的、不明显的、相对唯一的字母数字表示的哈希？

这本身不是 URL 缩短问题，因此如果哈希部分与 ID 部分的长度相同，我会感到满意:减少到 10 个字母数字字符是可以接受的。

另外，不一定每次访问URL都需要计算hash。可以在创建订单记录时或首次访问该订单 ID 的页面时计算它。这意味着哈希函数并不一定要很快。

尽管有可能为查找目的本质上创建一个哈希表，但这个问题没有与哈希表相同的限制:查找是基于一个已经唯一的值完成的，因此如果它足够，则冲突解决并不是绝对必要的对于给定的散列，很难找到具有相同散列的另一条记录。

我们现在完全超出了需要做什么来保护反馈表的实际领域 - 这些数据实际上并不是那么重要的保护 - 但请逗我，这是一个有趣的问题，我想知道是否有一个很好的解决方案可以最大限度地提高安全性和可读性。

Answer 1

从根本上说，这归结为一个非常简单的情况。

您有一个标识符命名空间，每个标识符有 n 位。此命名空间的大小为 2ⁿ。

在这个命名空间之外，您实际上只发出 v 个有效标识符。

用户偶然猜出其中一个有效标识符的概率是 p = v/2ⁿ。

你必须做出妥协。较大的 n 意味着较小的 p 但标识符更难输入/复制/记住。较小的 n 将使标识符更短，但会增加 p。

有帮助的一件事是标识符是否仅在有限的时间内有效。这允许您发布大量标识符而无需过多地增加 p，因为同时只有一小部分发布的标识符实际上是有效的。您的用例可能会也可能不会规定标识符的某个最小合理生命周期。

在任何情况下，标识符都应该基于随机数或包括 key 在内的几个事物的加密散列，以便与有意义的信息片段(如订单号或序列号/序列号)没有可辨别的关系。如果您使用散列并选择小于散列输出长度的 n，则截断散列是完全正确的。

将标识符编码为 URL 的最紧凑的方法是 base64 之类的东西。 base64 的缺点当然是编码的字符串对人类没有意义。您可以使用基于诸如从字典生成可发音的单词或单词序列之类的各种编码方案。这些对人类来说可能更令人难忘，但对于相同数量的熵，它们确实会比紧凑表示更长，因此可能不值得(特别是如果 URL 通常被点击、复制和粘贴，或作为 QR 码扫描) .