GUID 的不可猜测性如何？
不久前，我开发了一个网络应用程序，用户可以在其中购买门票。由于我们客户流程的工作方式，您在购买后实际上得到的是一个包含票号的 URL。
这些是在中东购买房产的门票，每张门票的潜在价值约为 3,000,000 美元。显然，给出连续整数是一个坏主意。我们使用 GUID，因为它们基本上是无法猜测的，但我的问题是：它们足够安全吗？
据我了解，.NET 生成的 GUID 完全是伪随机的（除了一些不变的位）。但是，我不知道使用什么算法来生成它们。
MSDN 文档告诉我们 Random 快速且不安全，并且 RNGCryptoServiceProvider 缓慢且安全。也就是说，可以合理地假设某人可以付出足够的努力来预测 Random 的结果，但不能预测 RNGCryptoServiceProvider 的结果。
如果您看到足够长的 GUID 序列，是否可以预测未来的 GUID？如果是这样，您需要看多少个？
[在我们的特殊情况下，稍后进行了物理安全检查 - 您必须出示用于购买机票的护照 - 因此，如果有人猜到了其他人的 GUID，那也不会太糟糕，所以我们当时并没有担心。使用 GUID 作为数据库密钥的便利性使其成为一种有用的数据类型。]
编辑：
所以答案是“不够”。
使用下面的 0xA3 的答案，以及来自 问题他链接到，以下代码将生成一个加密随机GUID，该GUID在RFC 4122 第 4.4 节：
static Guid MakeCryptoGuid()
{
// Get 16 cryptographically random bytes
RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider();
byte[] data = new byte[16];
rng.GetBytes(data);
// Mark it as a version 4 GUID
data[7] = (byte)((data[7] | (byte)0x40) & (byte)0x4f);
data[8] = (byte)((data[8] | (byte)0x80) & (byte)0xbf);
return new Guid(data);
}
这比 Guid.NewGuid() 生成 GUID 的速度要慢得多code>，但对于 122 位“非常随机”的数据，它们是安全不可预测的。
当然，任何加密随机文本都可以作为票号，但 GUID 非常方便。 :-)
与其他版本 4 GUID 一样，不能绝对保证唯一性，但可能性令人印象深刻。只要您的数量少于 326,915,130,069,135,865 （即 sqrt(-22^122ln(0.99))) GUID 同时运行，您可以 99% 以上确定不会发生冲突。换句话说：如果像我一样，你的应用程序将到处出现溢出错误，如果你有超过 int.MaxValue 的几乎任何东西，你可以超过 99.9999999999999999% 确定不会发生冲突（即e^-(((2^31-1)^2)/(2*2^122)))。这比您确信陨石不会在应用程序上线后一秒内消灭地球上的大部分生命（即 每 1 亿年一次）。
A while ago I worked on a web application where users could buy tickets. Due to the way our client's processes worked, what you effectively got as a result of your purchase was a URL with the ticket number in it.
These were tickets to buy property in the Middle East, and each ticket was potentially worth around $3,000,000. Clearly dishing out sequential integers would have been a bad idea. We used GUIDs as they're basically unguessable, but my question is: are they secure enough?
As I understand it, the GUIDs .NET produces are totally pseudo-random (except for a few non-varying bits). However, I don't know what algorithm is used to generate them.
The MSDN documentation tells us that Random is fast and insecure, and RNGCryptoServiceProvider is slow and secure. That is, it's reasonable to assume someone could put in enough effort to predict the outcome of Random, but not of RNGCryptoServiceProvider.
If you saw a long enough sequence of GUIDs, would it be possible to predict futures ones? If so, how many would you need to see?
[In our particular case there were physical security checks later on - you had to present the passport you used to buy your ticket - so it wouldn't have been too bad if someone had guessed someone else's GUID, so we didn't sweat it at the time. The convenience of using the GUID as a database key made it a useful datatype to use.]
Edit:
So the answer is "not enough".
Using 0xA3's answer below, and following links from the question he linked to, the following code will generate a cryptographically random GUID that's valid by Section 4.4 of RFC 4122:
static Guid MakeCryptoGuid()
{
// Get 16 cryptographically random bytes
RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider();
byte[] data = new byte[16];
rng.GetBytes(data);
// Mark it as a version 4 GUID
data[7] = (byte)((data[7] | (byte)0x40) & (byte)0x4f);
data[8] = (byte)((data[8] | (byte)0x80) & (byte)0xbf);
return new Guid(data);
}
This produces GUIDs much more slowly than Guid.NewGuid(), but with 122 bits of "very random" data, they are safely unpredictable.
Of course, any cryptographically random text would have done for a ticket number, but GUIDs are pretty handy. :-)
As with other version 4 GUIDs there's no absolute guarantee of uniqueness, but the odds are impressive. So long as you have fewer than 326,915,130,069,135,865 (i.e. sqrt(-22^122ln(0.99))) GUIDs in play simultaneously, you can be more than 99% sure there are no collisions. Put another way: if like mine your application will have overflow errors all over the place if you have more than int.MaxValue of pretty much anything, you can be more than 99.9999999999999999% sure of no collisions (i.e. e^-(((2^31-1)^2)/(2*2^122))). This is about a thousand times more sure than you can be that a meteorite won't wipe out most of life on Earth within one second of the application going live (i.e. one per 100 million years).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
UUID/GUID 由 RFC4122 指定。尽管版本 4 UUID 是根据随机数创建的，第 6 节 明确规定安全声明：
关于 GUID 随机性的一个很好的讨论也可以在这个问题中找到：
UUIDs/GUIDs are specified by RFC4122. Although Version 4 UUIDs are created from random numbers Section 6 makes an explicit statement on security:
A good discussion of the randomness of GUIDs can also be found in this question:
这是如何不考虑安全问题的完美示例。不幸的是，这就是大多数开发人员对安全性的看法......
不。可以使用大量资源来解决每张票可能支付 300 万美元的问题。那种钱可以吸引拥有大量资源的人……一些非常认真的人。使用任何依赖于通用随机数生成器的东西都不是很随机......因此不是很安全。它比密码学更容易混淆。
再说一遍，只要有那么多切达干酪就行...我可以给您提供您想要的任何护照。
是的。问题是...需要多长时间？ ...每个处理工作单元。
这取决于我对他们的创作的了解...操作系统、CPU 等...而且我确信我可以在贵公司找到有兴趣提供一些信息以换取的人。 ..100,000 美元，或者更有可能的是更少。
-- 这可能看起来有点过于戏剧化，但您谈论的是大量的资金，并且应该用大量的安全措施来保护它。您需要一家安全咨询公司来帮助您选择为此购买的加密包。您的客户应该能够通过他们的风险管理部门或保险公司提供帮助...如果没有，请聘请您自己的律师...您应该已经拥有的律师。
当然，GUID 方案出问题的可能性很小，但如果真的出了问题……你如何告诉所有那些律师，你的安全计划是一流的，他们应该寻找其他地方？ ..相信我，如果出现问题，您不想承担责任。那对你来说真的很糟糕。
编辑：根据 teedyay 的评论...
从客户那里获得“免费出狱”卡始终是一个好主意。如果你告诉他们“我们可以在轻微攻击的情况下确保其安全......但我们不是一家安全或密码公司。”那么你的工作就完成了，只剩下客户承担责任。
This is a perfect example of how not to think about a security issue. Unfortunately it is how a majority of developers think about security...
No. A lot of resources can be brought to bear on a problem that has a possible payout of $3M per ticket. That kind of money could attract people with a lot of resources...some very serious people. Using anything that relies on a general purpose random number generator is not very random...thus not very secure. It is more obfuscation than cryptography.
Again, with that amount of cheddar on the line... I can get you any passport you'd like.
Yes. The question is...How long would it take ? ...per some unit of processing work.
That depends on what I know about their creation...OS, CPU, etc...and I'm sure I can find somebody at your firm that would be interested in providing some information in exchange for say...$100,000 or, more likely, less.
-- This may all seem a bit overly dramatic, but you are talking about a serious amount of money and it should be protected with a serious amount security. You need a security consulting firm that can help you choose the encryption package you buy for this. Your client should be able to help via their risk management department or their insurer....If not, get your own lawyer...the one you should already have.
Of course, there is very little chance that anything would go wrong with the GUID scheme but if did go all pear shaped...How are you going to tell all those lawyers that your security plan was top notch and they should look elsewhere ?...Trust me, you do not want to be holding the bag if something goes wrong. That would really suck for you.
Edit: On teedyay's comment...
Obtaining a "Get Out of Jail Free" card from the client is always a good idea. If you tell them "We can make it secure in the case of trivial attacks...but we are not a security or cryptography firm." then your job is done and the client is left holding the bag.
GUID由众所周知的算法生成。没有内置的随机性，因为使用网卡 ID 和时间戳等众所周知的值来生成它们。它们绝不被用作安全手段。
编辑
似乎较新版本的
GUID/UUID算法不再使用硬件地址作为其部分值，而是使用伪随机数。但这些并不是真正随机的，仍然不应该用于安全关键应用程序。GUIDs are generated by a very well known algorithm. There is no randomness built-in as well known values such as network card ID's and timestamps are used to generate them.They should never be used as a means of security.
EDIT
It appears newer version of the
GUID/UUIDalgorithm no longer use hardware address for parts of their values and instead use pseudo-random numbers. But these are not truly random and still should not be used for security critical applications.从功能上来说
人们说GUID/UUID不安全。这是真的吗？
C#的GUID是一个128位整数，它意味着很多组合：170,141,183,460,469,231,731,687,303,715,884,105,727
但是假设我们的攻击者使用暴力破解，每次尝试需要0.1秒，你知道我们谈论了很多时间，所以没有人敢这么做那。
但假设 GUID 不“安全”，因此熵会减少到 32 位 (2,147,483,647)，这意味着强力暴力攻击可能会持续
2,147,483,647 x 0.1 秒 / 60 / 60 /24 = 2400 天。因此，即使 32 位 GUID 也是安全的（但它可能会产生冲突）。
我们可以说 GPU 或超级计算机可以在几秒钟内生成如此数量的组合。 是的，但是如果无法测试，生成值列表就没有任何意义。
此外，强制暴力攻击很容易识别，这就是我们所说的 DDOS，并且有多种方法可以缓解它。
从数学上来说，GUID是安全的，但是数学世界和现实世界差别太大。
Functionally speaking
People say that GUID / UUID is not safe. Is it true?
C#'s GUID is a 128-bit integer and it means a lot of combinations: 170,141,183,460,469,231,731,687,303,715,884,105,727
But let's say our attacker uses force brute and each attempt takes 0.1 seconds, you know that we are talking a lot of time, so nobody will even dare to do that.
But let's say GUID is not "safe", so the entropy is reduced to, let's say to 32-bits ( 2,147,483,647) it means a force brute attack could last
2,147,483,647 x 0.1 second / 60 / 60 /24 = 2400 days. So, even a 32-bit GUID is safe (but it could generates collisions).
We could argue that a GPU or a super-computer could generate that number of combinations in a snap of seconds. Yes, but generating a list of values means nothing if they can't be tested.
Also, a force brute attack is easily identifiable, it's what we call a DDOS and there are several ways to mitigate it.
Mathematically, GUID is safe but the mathematical world and the real world are too different.