security - 为什么要使用 chaffify ID 来为对象创建唯一的 URL？

Question

为什么开发人员要为他们的“用户”对象添加 ID，或者为什么 Twitter 使用 Snowflake对于消息 ID...？换句话说:为什么在浏览器中显示顺序 ID 不好？它代表安全漏洞还是仅仅是隐私问题？如果是安全漏洞，顺序 ID 会暴露什么漏洞？如果这是一个隐私问题，如果最终用户可以识别顺序 ID，那么隐私如何被侵犯？

Answer 1

创建唯一 ID 的三种常见方法是

使它们连续

选择一个相当大的随机数

选择 UUID，即试图“个性化”该号码，以便它不会被第二次创建

安全方面
如果您将 session 之类的内容与 ID 相关联，这肯定是一个安全问题。在这种情况下，您不希望任何恶意用户能够预测这样的 ID。顺序 ID 很容易预测，UUID 需要更多努力但也不是一个好主意，这会留下随机数。即使对于它们，您也必须确保使用加密安全的随机数生成器，否则仍有可预测性的空间。
作为为什么这很严重的示例，请考虑 URL 中包含的旧“jsessionid”或任何其他典型 session ID。攻击者会像普通用户一样登录并行为，记下分配给他的 session ID，然后开始预测更多 ID，并通过在地址栏中输入它们，有效地劫持其他用户的 session 。
并发/扩展问题
但是从 Snowflake 在其描述中所说的来看，似乎没有与之相关的固有安全问题，该方法似乎属于第三种，即 UUID 类别。在文本中，它说他们正在从 MySQL 迁移到 Cassandra，并且他们过去使用 MySQL 顺序 ID。但是，如果您考虑一下，当您尝试扩展系统时，这很快就会成为瓶颈:每个 ID 生成都需要同步以防止竞争条件。
如果您不同步此过程，则此类竞争条件的一个示例可能是两个独立的实例同时增加 ID，从而有效地将计数器仅增加 1，而实际上它应该增加 2。现在通常，如果您只有一个数据库实例，该数据库将为您执行同步。但显然这不能扩展，太多客户端将等待空闲，而数据库负载很重。多个数据库是一种选择，但复制 ID 可能会使您回到相同的情况。
无锁唯一 ID
因此，如果您希望在不需要同步(无锁)的情况下生成 ID，您要么学会忍受非唯一 ID(这或多或少是矛盾的，而不是真正的解决方案)，要么您必须想办法消除瓶颈。我们曾经做过的事情，以及对一些数据库实例很好的工作:

对于两个实例，一个 DB 只会生成奇数 ID，另一个只会生成偶数 ID。

对于 n 个实例，选择 n 个互质数，并将给定实例的 ID 乘以这些互质数中的一个。在三个数据库的情况下，选择例如2、3和5。基本数论确保不会有重复。

但在许多情况下，这将成为一个真正的数论问题，因此您必须寻求不同的解决方案。一种出路是走 UUID 路线，这通常是可以的，但缺点是完全取决于可能随时间变化的外部因素。据我所见，我猜这就是雪花的目标。
为完整起见，我想提及另一种可完美扩展且 IMO 本身美观的解决方案。它也不受外部因素的影响，可以在任何地方工作，尽管一开始是违反直觉的。这个想法是选择足够大(假设是 20 个字节)的密码安全随机数。它必须是那些非加密随机数生成器通常在生成一定数量的数字后重复，当然，我们不希望那样。除此之外，这就是你所需要的。
起初，我认为这永远行不通，如果我们得到相同的数字怎么办？但是，如果您进行数学计算，您就会意识到几率是多少。生日悖论告诉我们，你会发现一个时间顺序为 O(2^(n/2)) 的碰撞，其中 n 是你的随机数的位数。所以 20 字节 = 160 位，你应该在 2^80 时间内发现冲突。这与 SHA-1 的安全裕度相同，到目前为止还没有人在那里发现冲突。问题是，您很幸运并在例如 2^30 中通过“机会”或类似的东西发现碰撞的可能性很小。可能性对你不利。这与在同一天成为总统的同时赢得多个彩票大致相同。