GUID 在为 Web 应用程序创建会话密钥时被大量使用。我一直想知道这种做法的安全性。由于 GUID 是根据来自机器的信息、时间以及其他一些因素生成的，因此很难猜测未来可能出现的 GUID。假设您启动了 1000 个或 10000 个新会话，以获得正在生成的 GUID 的良好数据集。这是否会使生成可能用于另一个会话的 GUID 变得更容易。您甚至不必猜测特定的 GUID，只需继续尝试可能在特定时间段内生成的 GUID。
【问题讨论】：
这是来自Wikipedia (original source) 的一些内容：
包含 MAC 地址的 V1 GUID 和时间可以由 数字“1”在第一个位置 第三组数字，例如 {2f1e4fc0-81fd-11da-9156-00036a0f876a}。
据我了解，他们并没有真正隐藏它。
V4 GUID 使用后一种算法， 这是一个伪随机数。这些 在相同的位置有一个“4”，对于 例子 {38a52be4-9352-453e-af97-5c3b448652f0}。 更具体地说，“data3”位 模式将是 0001xxxxxxxxxxxx 在 第一种情况，0100xxxxxxxxxxxx 在第二。密码分析 WinAPI GUID 生成器显示， 因为 V4 GUID 的序列是 伪随机，给定初始状态 可以预测下一个 250 000 函数返回的 GUID UuidCreate1。 这就是 GUID 的原因 不应在密码学中使用，例如。 g.，作为随机键。
【讨论】：
38a52be4-9352-453e-af97-5c3b448652f0 才能找到维基百科的文章。我添加了一个指向原始俄罗斯来源的链接，其中提到了 250,000 个 GUID。
视情况而定。如果 GUID 设置合理，则很难，例如使用加盐的安全哈希，你有很多位。如果 GUID 短而明显，则说明它很弱。
您可能希望采取措施阻止某人创建 10000 个新会话，因为这可能会产生服务器负载。
【讨论】：
如果有人不断使用连续的 GUID 流访问服务器，那将更像是拒绝服务攻击。
有人猜测 GUID 的可能性几乎为零。
【讨论】：
.NET Web 应用程序调用 Guid.NewGuid() 来创建一个 GUID，该 GUID 最终调用CoCreateGuid() COM 函数在堆栈更深的几帧。
来自 MSDN 库：
CoCreateGuid 函数调用 RPC 函数 UuidCreate，它创建 一个 GUID，一个全球唯一的 128 位 整数。使用 CoCreateGuid 函数 当你需要一个绝对独特的 您将用作 分布式中的持久标识符 环境。到了非常高的程度 可以肯定的是，这个函数返回一个 唯一值——没有其他调用，在 相同或任何其他系统 （联网与否），应返回 相同的值。
如果你查看UuidCreate上的页面：
UuidCreate 函数生成一个 UUID 无法追踪到 以太网/令牌环地址 生成它的计算机。它 也不能与其他关联 UUID在同一台计算机上创建。
最后一个 contains 句子是您问题的答案。所以我想说，除非微软的实现中存在错误，否则很难猜测。
【讨论】：
GUID 保证是唯一的，仅此而已。不保证是随机的或难以猜测的。
要回答您的问题，至少对于 V1 GUID 生成算法，如果您知道算法、MAC 地址和创建时间，您可能会生成一组 GUID，其中一个是实际生成的。如果是 V1 GUID，则 MAC 地址可以从同一台机器的示例 GUID 中确定。
来自维基百科的其他花絮：
OSF 指定的算法 生成新的 GUID 已被广泛使用 批评。在这些 (V1) GUID 中， 用户的网卡MAC地址是 用作最后一组的基础 GUID 数字，这意味着，例如， 可以追溯到文档 创建它的计算机。这 定位时使用了隐私洞 梅丽莎蠕虫的创造者。最多 其他数字是基于 生成 GUID 的时间。
【讨论】：
“GUID 保证是唯一的，仅此而已”。 GUID 不保证是唯一的。至少是由 CoCreateGuid 生成的：“对于非常高的确定性，此函数返回一个唯一值——在相同或任何其他系统（网络或非网络）上没有其他调用，应该返回相同的值。”
【讨论】：