UUID 规范详细说明了几个“版本”，它们是生成 UUID的方法。大多数旨在通过使用例如当前日期来确保唯一性（这是 UUID 的要点）。这是有效的，但意味着虽然生成的 UUID 是唯一的，但它们也是可预测的，这使得它们不适用于某些安全用途。

然而，“版本 4”UUID 生成方法（在第 4.4 节中）应该使用加密强的随机数生成器。128 位中的 6 位固定为常规值（即表示这是版本 4 UUID），因此从 RNG 中留下了 122 位。

如果底层 RNG 是安全的（例如/dev/urandom在 Linux/MacOS/*BSD 系统或CryptGenRandom()Windows 上），那么给定许多生成的 UUID，攻击者不应该能够预测成功概率高于 2 ^-122的下一个，对于大多数用途来说，它足够小，包括核导弹的发射代码。

122个随机位保证了高概率的唯一性。^{如果您生成许多版本 4 UUID 并累积它们，您可能会在大约 2 61} UUID之后遇到您的第一次碰撞- 大约是 20 亿；仅存储该数量的 UUID 将使用超过 3000 万 TB 的数据。如果您考虑“仅”10 ^{12 个}这样的 UUID（一千亿，可存储超过 16 TB），那么在其中拥有两个相同 UUID 的风险约为 9.4*10 ^-14，即比赢得数百万的概率低约 70 万倍美元在彩票。

因此，当（且仅当）它们是使用安全 RNG 生成的“版本 4”UUID 时， UUID适合用于安全目的。

对于您描述的目的，它们是否足够安全？在我看来，通常是的。它们在安全性非常重要的应用程序中是否足够安全？不，它们是使用非随机算法生成的，因此它们在任何方面都不是加密随机或安全的。

所以对于取消订阅或订阅验证功能，我真的没有看到安全问题。另一方面，要识别在线银行应用程序的用户（或者甚至可能是身份有价值的网站的密码重置功能），GUID 绝对是不够的。

有关更多信息，您可能需要查看RFC 4122 的 GUID（或通用唯一标识符）的第 6 节（安全注意事项）。

它们在 Windows 2000 或更高版本上是安全的。您的漏洞和风险取决于 GUID 的生成方式。Windows 2000 或更新版本使用加密安全的 GUID 版本 4。

有关详细信息，请参阅此 MSDN 链接和此堆栈溢出问题。（感谢评论中的 Jordan Rieger）

如果您使用的是通用开发语言，使用适当的加密函数创建唯一随机数的一次性生成器并不是那么困难（我们谈论的是 10 行代码，这些代码可以作为最常用语言的示例，只需使用 Google ) 因此使用简单的新 guid 从开发人员的角度来看基本上是懒惰。

在所描述的场景中，它们“足够安全”，如果在忘记密码函数中传递的 Guid 具有一些基本功能：

1) 真的是一次性的值，和用户id没有关系，所以一旦密码被重置，就不能再使用了

2）它有一个定义的有效时间窗口（您可以在接下来的 30 分钟内重置密码或类似的时间）

如果使用相同的 Guid，您可以多次重置密码，或者猜测没有要求重置密码的用户的 guid 和重置密码，或者像评论中描述的 Avid 一样，尝试使用某种方式来访问重置密码重播附加然后是应用程序设计有问题，使用或不使用 Guid 并不是真正的问题。

因此，如果您不处理非常敏感的信息，那么也许 guid 可以工作，但为什么不第一次以正确的方式制作并使用适当的加密 api 来生成安全的随机字符串呢？

问候马西莫