GUID 在可预测性方面的安全性如何？
目前，我们使用 .NET 的 Guid.NewGuid() 来生成激活码和 API 密钥。我想知道这是否会带来安全问题，因为他们的算法是开放的。
.NET Guid 使用 Win32 CoCreateGuid，我不知道它的内部结构（可能是 MAC 地址 + 时间戳？）。有人可以从第一个 GUID 中得出第二个 GUID，或者他可以通过一些聪明的猜测来命中它，或者随机性是否足够好，因此搜索空间变得太大？
生成随机密钥存在冲突问题，在添加到数据库之前需要进行双重检查。这就是我们坚持使用 GUID 的原因，但我不确定它们用于这些目的的安全性。
以下是 4 个连续的 UUIDGEN 输出：
<前><代码>c44dc549-5d92-4330-b451-b29a87848993 d56d4c8d-bfba-4b95-8332-e86d7f204c1c 63cdf958-9d5a-4b63-ae65-74e4237888ea 6fd09369-0fbd-456d-9c06-27fef4c8eca5
以下是 Guid.NewGuid() 提供的 4 个：
<前><代码>0652b193-64c6-4c5e-ad06-9990e1ee3791 374b6313-34a0-4c28-b336-bb2ecd879d0f 3c5a345f-3865-4420-a62c-1cdfd2defed9 5b09d7dc-8546-4ccf-9c85-de0bf4f43bf0
We're using .NET's Guid.NewGuid() to generate activation codes and API keys currently. I wonder if that poses a security problem since their algorithm is open.
.NET Guid uses Win32 CoCreateGuid and I don't know its internals (possibly MAC address + timestamp?). Can someone derive a second GUID out of the first one, or can he hit it with some smart guesses or is the randomness good enough so search space becomes too big?
Generating random keys have the problem of collision, they need a double check before adding to a database. That's why we stuck with GUIDs but I'm unsure about their security for these purposes.
Here are the 4 consecutive UUIDGEN outputs:
c44dc549-5d92-4330-b451-b29a87848993 d56d4c8d-bfba-4b95-8332-e86d7f204c1c 63cdf958-9d5a-4b63-ae65-74e4237888ea 6fd09369-0fbd-456d-9c06-27fef4c8eca5
Here are 4 of them by Guid.NewGuid():
0652b193-64c6-4c5e-ad06-9990e1ee3791 374b6313-34a0-4c28-b336-bb2ecd879d0f 3c5a345f-3865-4420-a62c-1cdfd2defed9 5b09d7dc-8546-4ccf-9c85-de0bf4f43bf0
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
GUID 是相当随机的，但它们并不打算用作随机数 - 它们的唯一目的是唯一地标识实体，因此它们是可预测的。
改用 System.Security.Cryptography.RandomNumberGenerator。
GUIDs are quite random, but they are not intended to be used as random numbers - their sole purpose is to uniquely identify entities, so they can be predictable.
Use System.Security.Cryptography.RandomNumberGenerator instead.
任何密钥都有有限的空间，并且充分确定的人/组可以并且将会生成所有组合。重要的不是关键，而是如何组织验证以及授权什么。如果您完全通过 Guid 操作验证/授权，那么这可能不合适，因为可能所有 Guid 都是有效的，您最好使用类似 SeriousBit Elipter。如果您使用的身份验证机制记录了特定 Guid 已发布并且现已用于激活，那么 Guid 并不是一个糟糕的选择，因为它是一个相当大的密钥空间。
Any key has a finite space and a sufficiently determined person/group can and will generate all combinations. What's important is not so much the key but how you organise it's validation and what it authorises. If you are operating the validation/authorisation entirely through the Guid then that's probably not appropriate as potentially all Guids are valid, you'd be better off with something like SeriousBit Elipter. If you are using an authentication mechanism that records that a particular Guid has been issued and that it has now been used for activation then Guid isn't such a bad choice as it's a pretty big key space.
生成 guid 的机制有多种，有些使用 MAC 地址，有些仅使用纯随机数生成。 iirc 如果正在使用 amc 地址，则它应该在 GUID 中显而易见 - 它不会以任何方式散列出来。
编辑：附带条件，答案有点蹩脚，因为在这里我谈论的是通用 guid 生成，而不是可能混淆它的 ms 算法。正在研究，如果没用就删了。。
There are multiple mechanisms for generating guids, some using MAC addresses and some just using pure random number generation. iirc the amc address should be obvious in the GUID if it's being used - it's not hashed out in any way.
edit: proviso, slightly lame answer, as here I'm talking about generic guid generation rather than a possible ms algo that does obfuscate it. am looking into it, will delete if it's not useful ..