我们正在使用.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
答案 0 :(得分：10)
GUID非常随机，但它们并不打算用作随机数 - 它们的唯一目的是唯一地标识实体，因此它们是可预测的。
Use System.Security.Cryptography.RandomNumberGenerator instead
答案 1 :(得分：2)
任何键都有一个有限的空间，一个足够确定的人/组可以并将生成所有组合。重要的不仅仅是关键，而是如何组织它的验证以及它授权的内容。如果您完全通过Guid操作验证/授权，那么可能不适合所有Guids都有效，您最好使用SeriousBit Elipter之类的东西。如果您使用的是一种记录已发布特定Guid并且现在已用于激活的身份验证机制，那么Guid并不是一个糟糕的选择，因为它是一个非常大的密钥空间。
答案 2 :(得分：1)
有多种生成guid的机制，有些使用MAC地址，有些只使用纯随机数生成。如果它被使用，那么amc地址应该在GUID中显而易见 - 它不会以任何方式被删除。
编辑：proviso，稍微蹩脚的答案，因为我在这里谈论的是通用guid生成，而不是 混淆它的可能的ms算法。我正在研究它，如果没用就会删除..