它们之所以吸引人，是因为它们易于生成，唯一，非顺序且看起来是随机的。
但是它们是否足够安全用于这些目的？
在我看来，给定GUID，就可以预测后续的GUID，因为（据我所知）它们
注意：
我不是在谈论使用随机的gobbledygook斑点的网站以base64编码。
我说的是这样的站点，似乎使用的是原始Guid：
http://example.com/forgotPassword/?id=b4684ce3-ca5b-477f-8f4d-e05884a83d3c #1 楼
它们是否足以满足您描述的目的？我认为通常是这样。在对安全性非常关注的应用中，它们是否足够安全？否。它们是使用非随机算法生成的，因此它们在密码学上都不是随机的或安全的。因此，对于取消订阅或订阅验证功能，我确实没有看到安全问题。另一方面，要识别在线银行应用程序的用户（或者实际上甚至可能是身份很有价值的站点的密码重置功能），GUID绝对是不够的。
有关更多信息，您可能想查看RFC 4122中GUID（或通用唯一标识符）的第6节（安全注意事项）。
评论
他描述的目的正是密码重置功能。很明显，您说过GUID不能用于任何安全用途，但您的第一句话与此相反。
–AVID♦
2010-11-30在16:38
我同意大多数网站上的密码重置功能是可以接受的。不适用于银行网站或假设其他用户身份特别有价值的网站，但大多数网站根本不会为此类攻击提供足够的目标，或者对于此类攻击没有足够高的密码重置请求数量首先工作。
– Xander
2010-11-30在16:49
在我工作过的大多数组织中，密码重置的绝对安全级别都比对交易站点等的身份验证低。是的，它是攻击的载体，但是施加了限制（时间，对机密信息的了解等）并降低了成本通常认为在简化密码自重置（减少服务台呼叫节省金钱）方面，足够驱动程序。
–Rory Alsop♦
2010-11-30 18:26
嗯，我想是真的，对于低价值网站，GUID可能已经足够了。但是确实，正如@massimo在他的回答中提到的，为什么要打扰？加密数字在开发时间或处理时间上都不昂贵。
–AVID♦
2010-11-30 19:56
点了。我同意，即使它们适合手头的目的，但从安全角度来看，它们仍然不是最佳选择。
– Xander
2010-11-30 21:45
#2 楼
UUID规范详细介绍了几种“版本”，它们是用于生成UUID的方法。大多数旨在通过使用例如当前日期来确保唯一性（这是UUID的重点）。这是有效的，但是意味着尽管生成的UUID是唯一的，但它们也是可预测的，因此不足以用于某些安全用途。“版本4” UUID生成方法（在4.4节中）应该使用加密强度高的随机数生成器。 128位中的6位固定为常规值（即表示这是版本4 UUID），因此这会保留RNG中的122位。
如果基础RNG是安全的（例如在Linux / MacOS / * BSD系统上为
/dev/urandom，在Windows上为CryptGenRandom()），然后给定许多生成的UUID，攻击者不应该能够预测下一个成功概率大于2-122的攻击者，这对于大多数攻击者来说足够小用途，包括核导弹的发射代码。122个随机位可确保唯一性并具有很高的概率。如果生成许多版本4 UUID并进行累积，则可能会在大约261 UUID之后遇到第一次碰撞-这大约是20亿亿。仅存储该数量的UUID将使用超过3,000万兆兆字节。如果您考虑“仅” 1012这样的UUID（千亿，可存储超过16 TB），那么在其中拥有两个相同的UUID的风险约为9.4 * 10-14，即，比赢得数百万美元的可能性低约70万倍因此，只要（且仅当）UUID是使用安全RNG生成的“版本4” UUID，UUID才适用于安全目的。
评论
它说：“版本4 UUID用于从真正随机或伪随机数生成UUID。” （FWIW）...
–rogerdpack
20 Mar 6 '20 at 1:28
#3 楼
它们在Windows 2000或更高版本上是安全的。您的漏洞和风险取决于GUID的生成方式。 Windows 2000或更高版本使用加密的GUID版本4。有关更多信息，请参见此MSDN链接和此堆栈溢出问题。 （感谢乔丹·里格的评论）
评论
为什么通过加密不是那么随机的数字来使事情复杂化？更好，更简单地生成一个真正不可预测的随机数。在Linux上使用/ dev / random或/ dev / urandom可以轻松实现。对于其他平台，我们只需要一个简单的特定配方。
–nealmcb
2011-1-30在16:27
@nealmcb有时无法定义此数字的随机性（例如，ID来自第三方的后端系统）。可能不适用OP
–半音
17年2月17日在18:45
根据msdn.microsoft.com/zh-cn/library/…的说法，自Windows 2000早在1999年以来，“ Windows中内置的所有第4版GUID的随机位都是通过Windows CryptGenRandom加密API或等效的相同来源获得的。用于生成加密密钥”。因此，我想您可以称其为加密安全-至少达到它们提供的122位熵的程度。
–乔丹·里格（Jordan Rieger）
18年5月28日在19:45
@JordanRieger谢谢-更新。我试图找到包含文档“ home”，但受到MSDN导航的阻碍。该产品文档是否针对“ .NET”，“ Windows”或其他？
–半音
18年5月28日在21:25
@ CHICoder007 MSDN导航似乎已损坏。尽可能使节号后面向后导致msdn.microsoft.com/en-us/library/…，这是一个死胡同。绝对是某种Windows SDK文档。我是通过在此博客文章上绊跌而找到的：joakim.uddholm.com/posts/predicting-net-guidnewguid.html（此后该文档页面可能已更新，因为该博客实际上在注释11的末尾引用了注释9。）这也与Will Dean最近在stackoverflow.com/a/35384818/284704中进行的调试/逐步调试相匹配。
–乔丹·里格（Jordan Rieger）
18年5月29日在0:26
#4 楼
如果您使用的是通用开发语言，那么使用适当的加密功能创建唯一随机数的单发生成器并不是那么困难（我们谈论的是仅使用Google就能获得的10行代码，这些代码可以作为最常见语言的示例） ），因此从开发人员的角度来看，使用一个简单的新guid基本上是懒惰。在所描述的方案中，它们“足够安全”，如果传递给忘记密码功能的Guid具有一些基本功能：
1）这实际上是一个单发值，与用户ID无关，因此，一旦重置密码，就不能再使用了
2）定义的有效时间窗口（您可以在接下来的30分钟之内重设密码）
如果使用相同的Guid，则可以多次重设密码，也可以猜测一下GUId并重设不要求重设密码的用户的密码，或者像评论中的Avid所述，尝试获取重设权限的用户的密码使用某种重播附件的密码，那么应用程序设计有问题，使用或不使用Guid并不是真正的问题。
因此，如果您不处理非常敏感的信息，则可能是guid可以工作，但是为什么第一次不以正确的方式进行处理，并使用正确的crypto API生成安全的随机字符串？
问候
Massimo
评论
我同意您的答案的第一部分，即生成加密随机数非常容易（并且所需的LoC基本上应少于10。）。但是，在所描述的情况下，它们不够安全，因为不能保证立即重置密码：通常存在不平凡的有效性窗口。
–AVID♦
2010-11-30在16:40
例如，请考虑以下因素：通常，此方案用于将链接发送到用户的预注册电子邮件，这将允许直接访问以重置用户的密码。作为攻击者，我将生成足够的这些链接/ GUID，直到我可以半可靠地计算出下一批，然后要求将链接发送给受害者（本质上是让用户要求重置密码）。然后，我将不在乎访问用户的电子邮件，因为我只能猜测GUID /链接。
–AVID♦
2010-11-30在16:44
@Rory，我在谈论GUID的固有可猜测性（给定足够的先前数据），而不是重放攻击...
–AVID♦
2010-11-30 19:55
#5 楼
微软公司的雷蒙德·陈（Raymond Chen）认为，自2000年以来Windows中使用的第4版GUID都不是加密安全的。他们使用基本的随机数生成器，如果他们知道生成器的状态，则可以允许某人预测过去和将来的GUID。当然，这仅与安全敏感的应用程序有关。重要的是要知道，标准Guid.NewGuid（）值只能保证“最肯定”是唯一的，而不是安全的。#6 楼
伪造的“ GUID”不是通过任何GUID生成算法生成的，而是由加密安全的PRNG生成的简单的128位（16字节），并且仅使用常规的GUID带连字符的十六进制表示。对于一次性令牌来说，大多数情况下都是安全的。但是，您确实遇到了生日问题，因为对于128位令牌而言，冲突的发生范围大约为2 ^ -64。
最好使用256位或512位令牌，其中存在冲突的位置大约为2 ^ -128或2 ^ -256。
评论
这是完全不正确的，至少在一般情况下是不正确的。如果您以@Thomas的答案为基础，那么它看起来似乎更合理，但仍不如他的准确。
–迈克尔·哈伦（Michael Haren）
2011年10月7日17:38
现在应该更清楚了。
– yfeldblum
2011年10月7日17:50
评论
这取决于您是否可以创建/预测下一个正在使用的GUID。给定操作变量或足够的先前GUID，GUID的生成几乎是确定性的（实际上并不需要太多...）
这完全取决于您对GUID的含义及其生成方式。查看URL似乎是UUID格式，您可能会猜到它是由Microsoft不安全的GUID算法生成的，因此它不适合您建议的用途。但是它可能是使用Linux中的/ dev / random之类的良好加密安全的伪随机源生成的，在这种情况下就可以了。
@nealmcb，它不仅仅是MS的实现，它是GUID的标准。
@avid我们同意RFC中没有任何内容指定类型4“随机” UUIDS也是加密安全的。我唯一的观点是，出于安全目的，您可以使用RFC的良好实现。例如。在具有/ dev / random的现代Linux机器上，默认情况下libuuid库（和uuidgen程序）将生成非常好的，不可预测的UUID。 kernel.org/doc/man-pages/online/pages/man4/random.4.html但是，安全软件直接使用专门提供加密随机性的API肯定会更好，因为有人可能会不小心移植代码。