为什么开发人员会为其“用户”对象查询ID，或者为什么Twitter会使用Snowflake来获取消息ID ...？换句话说：为什么顺序ID在浏览器中显而易见？它是代表安全漏洞还是仅仅是隐私问题？如果这是一个安全漏洞，顺序ID会暴露哪些漏洞？如果这是一个隐私问题，如果最终用户可以识别顺序ID，那么隐私会如何被侵犯？
答案 0 :(得分：3)
创建唯一ID的三种常用方法是
如果您将会话等内容与ID相关联，这肯定是一个安全问题。在这种情况下，您不希望任何恶意用户能够预测此类ID。顺序ID很容易预测，UUID需要更多的努力，但也不是一个好主意，留下随机数。即使对于他们来说，你必须确保使用加密安全的随机数发生器，否则仍有可预测性的空间。
作为一个例子，为什么这是严重的，考虑好的旧“jsessionid”或URL中包含的任何其他典型的会话ID。攻击者将登录并像普通用户一样行动，记下分配给他的会话ID，然后开始预测更多ID，并在地址栏中输入，有效地劫持其他用户的会话。
但从Snowflake在其描述中所说的内容来看，似乎没有与之相关的固有安全问题，这种方法似乎属于第三类UUID类别。在文中，它表示他们正在从MySQL迁移到Cassandra，并且他们过去使用的是MySQL序列ID。但是如果您考虑一下，当您尝试扩展系统时，这很快就会成为瓶颈：每个ID生成都需要同步以防止竞争条件。
如果你没有同步这个过程，这种竞争条件的一个例子可能是两个独立的实例同时增加了ID，因此有效地将计数器仅递增一个应该实际增加2的计数器。现在通常，如果您只有一个数据库实例，则数据库将为您执行同步。但显然这不会扩展，太多客户端将等待空闲，而数据库负载很重。多个数据库是一个选项，但复制ID可能会让您回到相同的状态。
因此，如果您希望生成ID而无需同步（无锁），您要么学会使用非唯一ID（这或多或少是一个Oxymoron，而不是真正的解决方案），或者您必须想出一些东西消除瓶颈。我们曾经做过什么，以及对于一些数据库实例很有效：
但是对于许多情况来说，这将成为一个真正的数论理论问题，所以你必须寻求不同的解决方案。一种方法是使用UUID路线，这通常是可以的，但其缺点完全取决于可能随时间变化的外部因素。从我所看到的情况来看，我的猜测就是Snowflake的目标。
为了完整起见，我想提到另一种解决方案，它可以很好地扩展，并且本身就是IMO。它不受外部因素的影响，并且可以在任何地方工作，尽管最初是反直觉的。我们的想法是选择足够大（假设20个字节）的加密安全随机数。它必须是那些非加密随机数生成器通常在生成一定数量的数字后重复，当然我们不希望这样。除此之外，这就是你所需要的一切。
起初，我认为这是行不通的，如果我们得到相同的数字怎么办？但如果你做数学计算，你会发现可能性是多少。生日悖论告诉我们你会发现O（2 ^（n / 2））的时间碰撞，其中n是随机数的位数。所以20个字节= 160位，你应该在2 ^ 80时间内发现碰撞。这与SHA-1的安全边际相同，到目前为止还没有人发现过碰撞。事情是你甚至不太可能幸运地发现碰撞让我们说2 ^ 30被“机会”或类似的东西。概率对你不利。在与同一天成为总统的同时赢得多个彩票的过程大致相同。