对像美国总统这样的高估资产进行成功的攻击非常容易（这是一个很大的电话），但前提是：
- 您知道总统车队的确切地点，时间和速度
- 总统将坐在哪个野兽，当时他将要做什么。
- 当天总统的行程，安全协议以及他的安全团队的通常习惯等
好吧，这是恐怖主义的大师班
您问，所有这些恶作剧与网络开发和API安全有什么关系？好吧，这很简单：可预测的系统本质上是不安全的。
这就是为什么建议您不要对用户的密码进行加密，而不仅要哈希，还要求它们加盐。
所以当我看到使用UUID代替普通的旧顺序ID是Treblle API security Hackathon上的一件事时，这并不令人惊讶。
正如可以在对公众人物的攻击中轻松利用可预测的系统一样，恶意参与者可以将可预测的系统揭示敏感信息并危害整个系统的完整性。
但是有一个问题...
采取强大的安全措施来增强系统的弹性并降低未经授权访问或开发的风险。
让我们以UUID而不是普通的顺序ID（MongoDB中的ObjectID）。是的，他们有：
- 普遍的唯一性。
- 独立于中央协调。
- 降低ID碰撞的风险。
- 灵活性和互操作性。
- 未来的范围，可扩展性和所有好东西...
但是要花多少钱？...
这是他们的长度吗？
它们可能长时间，以至于它们占据了我的数据库列或API有效载荷的一半。我只是想存储或传输一个简单的标识符，但是不，我必须处理这个似乎永远持续的可怕弦。这不仅是不便的，而且还浪费了有价值的存储和网络带宽。
让我们谈谈调试
出现问题时，我需要潜入数据库或日志以查找问题记录时，我用来根据其ID快速识别它。但是有了UUID，我需要复制这种怪兽，并希望我不会犯任何错误。祝你好运，在一个隐秘的弦线上找到那根针头。
关于性能
与简单地增加顺序ID相比，生成UUID需要更多的计算资源。因此，如果我要处理高通量系统或大量记录，则UUID生成的开销开始成为真正的瓶颈。
哦，甚至不要让我开始分类或索引uuids。
有了顺序的ID，这很轻松。
我可以简单地按照它们的价值订购，瞧！
但是使用uuid，就像试图解决一个复杂的难题一样。我必须求助于奇怪的排序算法，将它们转换为二进制表示形式，或将它们分成多个列，以使它们有些排序。
对于任何重视简单性和效率的人来说，这都是一场噩梦。
uuid有自己的好处，但权衡是真实的。
但是不要误会我的意思！
尽管可预测性是对攻击的开放邀请，而惊喜的要素可以转变为据点 - 并非所有场景都需要或受益于完全不可预测性。
请记住，当涉及面向人体的界面时，直观且令人难忘的ID对于良好的用户体验至关重要。
用户应该能够根据其ID轻松识别和记住实体或项目。这在用户需要经常参考或对特定项目进行交流的应用程序中尤其重要。
以及大多数应用程序，例如电子商务平台，CMS（内容管理系统）和数据分析平台具有特定的分类和索引需求。
没有一种适合所有解决方案。
您的选择应驱动您的申请要求，特定需求以及您愿意进行的权衡。
- 评估它们。
- 考虑好处。
- 权衡限制。
这是做出明智决定的唯一方法。这是本文的目标。
一个很大的音符 -
在整个历史上，不幸的是，对包括国家元首在内的公众人物的攻击发生了。重要的是要注意，讨论这些事件不应被视为认可或促进暴力。