使用 GUID 是否安全？
如果您使用 GUID 作为面向公众的应用程序的密码来获取服务访问权限，这种安全性是通过隐匿性实现的吗？
我认为显而易见的答案是肯定的，但安全级别对我来说似乎非常高，因为猜测 GUID 的机会非常非常低，对吗？
更新
GUID 将存储在设备中，插入后，将通过 SSL 连接发送 GUID。
也许我可以生成一个 GUID，然后对 GUID 进行 AES 128 位加密并将该值存储在设备上？
If you use a GUID as a password for a publicly facing application as a means to gain access to a service, is this security through obscurity?
I think the obvious answer is yes, but the level of security seems very high to me since the chances of guessing a GUID is very very low correct?
Update
The GUID will be stored in a device, when plugged in, will send over the GUID via SSL connection.
Maybe I could generate a GUID, then do a AES 128 bit encrption on the GUID and store that value on the device?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（12）
在我看来，答案是否定的。
如果你将密码设置为新创建的GUID，那么它是一个相当安全的密码：超过8个字符，包含数字，字母和特殊字符等。
当然，在GUID中
'{'的位置、'}'和'-'都是已知的，而且所有字母都是大写的。 因此，只要没有人知道您使用 GUID，密码就更难破解。 一旦攻击者知道他正在寻找 GUID，暴力攻击所需的工作量就会减少。 从这个角度来看，它是“默默无闻的安全”。不过，请考虑以下 GUID：
{91626979-FB5C-439A-BBA3-7715ED647504}如果您假设攻击者知道特殊字符的位置，那么他的问题就简化为查找字符串91626979FB5C439ABBA37715ED647504< /代码>。 暴力破解 32 个字符的密码？ 如果有人发明了一台可用的量子计算机，这只会在你的一生中发生。这是通过使用非常非常长的密码实现的安全性，而不是通过晦涩难懂。
编辑：
阅读 Denis Hennessy 的答案后，我必须修改答案。 如果 GUID 确实以可解密的形式包含此信息（特别是 MAC 地址），则攻击者可以大大减少密钥空间。 在这种情况下，它肯定是默默无闻的安全性，请阅读：相当不安全。
当然，MusiGenesis 是对的：有很多工具可以生成（伪）随机密码。 我的建议是坚持其中之一。
In my opinion, the answer is no.
If you set a password to be a newly created GUID, then it is a rather safe password: more than 8 charcters, contains numbers, letters ans special characters, etc.
Of course, in a GUID the position of
'{','}'and'-'are known, as well as the fact that all letters are in uppercase. So as long as nobody knows that you use a GUID, the password is harder to crack. Once the attacker knows that he is seeking a GUID, the effort needed for a brute force attack reduces. From that point of view, it is security by obscurity.Still, consider this GUID:
{91626979-FB5C-439A-BBA3-7715ED647504}If you assume the attacker knows the position of the special characters, his problem is reduced to finding the string91626979FB5C439ABBA37715ED647504. Brute forcing a 32 characters password? It will only happen in your lifetime, if someone invents a working quantum computer.This is security by using a very, very long password, not by obscurity.
EDIT:
After reading the answer of Denis Hennessy, I have to revise answer. If the GUID really contains this info (specifically the mac address) in a decryptable form, an attacker can reduce the keyspace considerably. In that case it would definitely be security by obscurity, read: rather insecure.
And of course MusiGenesis is right: there are lots of tools that generate (pseudo) random passwords. My recommendation is to stick with one of those.
实际上，使用 GUID 作为密码并不是一个好主意（与提出等效长度的真正随机密码相比）。 虽然看起来很长，但实际上只有 16 个字节，通常包括用户的 MAC 地址、日期/时间和一个较小的随机元素。 如果黑客可以确定用户的 MAC 地址，那么猜测他可能生成的 GUID 就相对简单。
Actually, using a GUID as a password is not a good idea (compared to coming up with a truly random password of equivalent length). Although it appears long, it's actually only 16 bytes which typically includes the user's MAC address, the date/time and a smallish random element. If a hacker can determine the users MAC address, it's relatively straightforward to guess possible GUID's that he would generate.
如果可以观察到正在发送的 GUID（例如通过 HTTP Auth），那么它的可猜测程度就无关紧要了。
某些网站（例如 Flickr）使用 API 密钥和秘密密钥。 密钥用于通过 MD5 哈希创建签名。 服务器使用密钥计算相同的签名并以这种方式进行身份验证。 秘密永远不需要通过网络传播。
If one can observe the GUID being sent (e.g. via HTTP Auth), then it's irrelevant how guessable it is.
Some sites, like Flickr, employ an API key and a secret key. The secret key is used to create a signature via MD5 hash. The server calculates the same signature using the secret key and does auth that way. The secret never needs to go over the network.
GUID是为了防止意外碰撞，而不是故意碰撞。 换句话说，您不太可能猜到 GUID，但如果您真的想猜的话，找出来并不一定困难。
GUID is to prevent accidental collisions, not intentional ones. In other words, you are unlikely to guess a GUID, but it is not necessarily hard to find out if you really want to.
起初我准备给出无条件的“是”，但这让我思考这是否意味着所有基于密码的身份验证都是隐秘的安全性。 从最严格的意义上来说，我认为在某种程度上是这样。
但是，假设您有使用密码登录的用户，并且您没有在任何地方发布该 GUID，我认为用户拥有的不太安全的密码甚至是系统管理员密码所带来的风险会超过风险。
如果您说过未受其他保护的管理页面的 URL 包含硬编码的 GUID，那么答案肯定是肯定的。
At first I was ready to give an unqualified yes, but it got me thinking about whether that meant that ALL password based authentication is security by obscurity. In the strictest sense I suppose it is, in a way.
However, assuming you have users logging in with passwords and you aren't posting that GUID anywhere, I think the risks are outweighed by the less secure passwords the users have, or even the sysadmin password.
If you had said the URL to an admin page that wasn't otherwise protected included a hard coded GUID, then the answer would be a definite yes.
我同意大多数其他人的观点，即它比弱密码更好，但最好使用更强大的密码，例如用于此类身份验证的证书交换（如果设备支持它）。
我还会确保您进行某种相互身份验证（即让设备验证服务器 SSL 证书以确保它是您期望的证书）。 我很容易抓住设备，将其插入我的系统，并从中读取 GUID，然后将其重放回目标系统。
I agree with most other people that it is better than a weak password but it would be preferable to use something stronger like a certificate exchange that is meant for this sort of authentication (if the device supports it).
I would also ensure that you do some sort of mutual authentication (i.e. have the device verify the servers SSL certificate to ensure it is the one you expect). It would be easy enough of me to grab the device, plug it into my system, and read the GUID off of it then replay that back to the target system.
一般来说，如果您在设备中嵌入密钥，或者在身份验证期间传输密钥，则会引入安全漏洞。 它们的密钥是 GUID 还是密码并不重要，因为唯一的加密差异在于它们的长度和随机性。 在任何一种情况下，攻击者都可以扫描您产品的内存或窃听身份验证过程。
您可以通过多种方式缓解这种情况，每种方式最终都可以归结为增加密钥的模糊性（或保护级别）：
在存储密钥之前对其进行加密。 当然，现在您需要存储该加密密钥，但是您已经引入了一定程度的间接性。
计算密钥，而不是存储它。 现在，攻击者必须对您的算法进行逆向工程，而不是简单地搜索密钥。
在身份验证过程中传输密钥的哈希，而不是像其他人建议的那样传输密钥本身，或者使用挑战响应身份验证。 这两种方法都会阻止密钥以明文形式传输。 SSL 也可以实现这一点，但是您需要依赖用户来维护正确的实现； 您失去了对安全性的控制。
与往常一样，每当您解决安全问题时，您都需要考虑各种权衡。 攻击的可能性是多少？ 如果攻击成功，风险是什么？ 就开发、支持和可用性而言，安全性的成本是多少？
一个好的解决方案通常是一个折衷方案，能够令人满意地解决这些因素。 祝你好运！
In general, you introduce security vulnerabilities if you embed the key in your device, or if you transmit the key during authentication. It doesn't matter whether they key is a GUID or a password, as the only cryptographic difference is in their length and randomness. In either case, an attacker can either scan your product's memory or eavesdrop on the authentication process.
You can mitigate this in several ways, each of which ultimately boils down to increasing the obscurity (or level of protection) of the key:
Encrypt the key before you store it. Of course, now you need to store that encryption key, but you've introduced a level of indirection.
Calculate the key, rather than storing it. Now an attacker must reverse-engineer your algorithm, rather than simply searching for a key.
Transmit a hash of the key during authentication, rather than the key itself, as others have suggested, or use challenge-response authentication. Both of these methods prevent the key from being transmitted in plaintext. SSL will also accomplish this, but then you're depending on the user to maintain a proper implementation; you've lost control over the security.
As always, whenever you're addressing security, you need to consider various tradeoffs. What is the likelihood of an attack? What is the risk if an attack is successful? What is the cost of security in terms of development, support, and usability?
A good solution is usually a compromise that addresses each of these factors satisfactorily. Good luck!
至少比使用“password”作为密码要好。
我不认为 GUID 会被视为强密码，而且有很多强密码生成器，您可以像 Guid.NewGuid() 一样轻松使用它们。
It's better than using "password" as the password, at least.
I don't think a GUID would be considered a strong password, and there are lots of strong password generators out there that you could use just as easily as Guid.NewGuid().
这实际上取决于你想做什么。 使用 GUID 作为密码本身并不安全（但要注意，GUID 包含 128 位总数中的许多可猜测的位：有一个时间戳，有些包括生成它的计算机的 MAC 地址等）但真正的问题是如何存储密码并将其传送到服务器。
如果密码存储在永远不会向最终用户显示的服务器端脚本中，则不会有太大风险。 如果密码嵌入在用户下载到自己计算机上的某些应用程序中，那么您将不得不混淆应用程序中的密码，并且没有办法安全地做到这一点。 通过运行调试器，用户将始终能够访问密码。
It really depends on what you want to do. Using a GUID as password is not in itself security through obscurity (but beware the fact that a GUID contains many guessable bits out of the 128 total: there is a timestamp, some include the MAC address of the machine that generated it, etc.) but the real problem is how you will store and communicate that password to the server.
If the password is stored on a server-side script that is never shown to the end user, there is not much risk. If the password is embedded in some application that the user downloads to its own machine, then you will have to obfuscate the password in the application, and there is no way to do that securely. By running a debugger, a user will always be able to access the password.
当然，这是默默无闻的安全。 但这有坏处吗？ 任何“强”密码都是隐秘的安全性。 您指望身份验证系统是安全的，但最终如果您的密码很容易被猜到，那么身份验证系统有多好都无关紧要。 因此，您设置了一个“强”且“模糊”的密码，以使其难以猜测。
Sure it is security by obscurity. But is this bad? Any "strong" password is security by obscurity. You count on the authentication system to be secure, but in the end if your password is easy to guess then it doesn't matter how good the authentication system is. So you make a "strong" and "obscure" password to make it hard to guess.
只有通过模糊性才能保证安全，就像密码一样。 使用 GUID 作为密码的主要问题可能是仅使用字母和数字。 然而，与大多数密码相比，GUID 相当长。 没有任何密码可以安全地进行彻底的搜索； 这是很明显的。 仅仅因为 GUID 可能有也可能没有某种时间戳或 MAC 地址的基础，这在某种程度上是无关紧要的。
猜出它和猜出其他东西的概率差异非常小。 某些 GUID 可能比其他 GUID 更“容易”（即：更快）被破坏。 越长越好。 然而，字母表的多样性也更好。 但再次，详尽的搜索揭示了一切。
It's only security through obscurity to the extent that that's what passwords are. Probably the primary problem with using a GUID as a password is that only letters and numbers are used. However, a GUID is pretty long compared to most passwords. No password is secure to an exhaustive search; that's pretty obvious. Simply because a GUID may or may not have some basis on some sort of timestamp or perhaps a MAC address is somewhat irrelevant.
The difference in probability of guessing it and something else is pretty minimal. Some GUIDs might be "easier" (read: quicker) to break then others. Longer is better. However, more diversity in the alphabet is also better. But again, exhaustive search reveals all.
我建议不要使用 GUID 作为密码（除非作为稍后更改的初始密码）。 任何必须写下来才能记住的密码
本质上都是不安全的。 它会被写下来。编辑：“本质上”是不准确的。 查看评论中的对话
I recommend against using a GUID as a password (except maybe as an initial one to be changed later). Any password that has to be written down to be remembered is
inherentlyunsafe. It will get written down.Edit: "inherently" is inaccurate. see conversation in comments