我知道GUID在理论上是独一无二的，碰撞的可能性很小。但是，如果我正确理解了某些独特性，因为它根据使用的算法从用于生成它的计算机上的信息中播种。
给定GUID用户可能猜出表中的其他GUID的可能性有多大？
例如，如果您的简报订阅者具有取消订阅功能，您可以将其发布到example.com/subscriber/unsubscribe/{id}
使用整数标识这显然是一个坏主意。 ID为1000的用户可以通过猜测ID在几秒钟内取消订阅整个数据库。
如果ID列是初始化为newid的GUID（），如果用户知道他们的ID，那么他们猜测ID的可能性有多大？
答案 0 :(得分：3)
我认为这在理论上可能是可能的，但实际上非常非常不可能发生。
我已经阅读了Eric Lippert的博客文章，其中SLaks在他的评论中链接了，以及Stack Overflow上的其他一些答案：
据我了解：给定一组几个GUID，可能会发现它们是否是在同一台机器上生成的。但要找出来并不容易，当然也不是普通用户。
现在我想只有一个 GUID（示例中的简报订阅ID），非常难以猜出任何其他GUID。
如果（并且仅当）它确实可能，您可能需要快速的机器并且深入了解用于创建GUID的算法。
最后，你必须看一下背景：
即使有可能猜出GUID（而且我不确定它是 - 我确定我无法做到），我无法想象有人会真的这样做这是为了取消订阅您的简报中的其他人。
答案 1 :(得分：2)
NEWID（）生成第4版GUID，但它的实现是 guessable 。 GUIDs are designed to be unique, not random.
来自RFC 4122规范：
安全注意事项
不要以为UUID难以猜测;不应该使用它们 作为安全能力（仅仅拥有授权的标识符） 访问），例如。可预测的随机数源将为 加剧了局势。
正如@ martin-smith所指出的那样，仅仅是因为它是版本4的投诉GUID并没有使其具有内在的可猜测性，这取决于实现。 This stackexchange post显示了如何使用不可猜测的SQL创建投诉版本4 GUID：
SELECT CAST(CRYPT_GEN_RANDOM(16) AS UNIQUEIDENTIFIER)
<强>参考文献：