如果您使用 GUID 作为面向公众的应用程序的密码作为访问服务的一种方式，这种安全性是通过默默无闻实现的吗？
我认为显而易见的答案是肯定的，但安全级别对我来说似乎非常高，因为猜测 GUID 的机会非常低，正确吗？
更新
GUID 将存储在设备中，插入后，将通过 SSL 连接通过 GUID 发送。
也许我可以生成一个 GUID，然后在 GUID 上执行 AES 128 位加密并将该值存储在设备上？
Blankman
问问题
14250 次
12 回答
15
在我看来，答案是否定的。
如果您将密码设置为新创建的 GUID，那么它是一个相当安全的密码：超过 8 个字符，包含数字、字母和特殊字符等。
当然，在 GUID 中 和 的位置是已知的'{'，'}'以及'-'所有字母都是大写的事实。因此，只要没有人知道您使用 GUID，密码就更难破解。一旦攻击者知道他正在寻找一个 GUID，暴力攻击所需的努力就会减少。从这个角度来看，它是默默无闻的安全。
不过，请考虑这个 GUID：{91626979-FB5C-439A-BBA3-7715ED647504}如果您假设攻击者知道特殊字符的位置，那么他的问题就会简化为查找字符串91626979FB5C439ABBA37715ED647504。暴力破解 32 个字符的密码？如果有人发明了一台工作的量子计算机，它只会在你的一生中发生。
这是通过使用非常、非常长的密码而不是晦涩难懂的安全性。
编辑： 阅读丹尼斯轩尼诗的答案后，我必须修改答案。如果 GUID 确实以可解密的形式包含此信息（特别是 mac 地址），则攻击者可以大大减少密钥空间。在那种情况下，它肯定是obscurity 的安全性，阅读：相当不安全。
当然，MusiGenesis 是对的：有很多工具可以生成（伪）随机密码。我的建议是坚持其中之一。
于 2008-11-14T15:40:04.573 回答
13
实际上，使用 GUID 作为密码并不是一个好主意（与想出一个等长的真正随机密码相比）。虽然看起来很长，但实际上只有 16 个字节，通常包括用户的 MAC 地址、日期/时间和一个小的随机元素。如果黑客可以确定用户的 MAC 地址，那么猜测他可能生成的 GUID 相对简单。
于 2008-11-14T15:31:53.593 回答
10
如果可以观察到正在发送的 GUID（例如通过 HTTP Auth），那么它的可猜测性就无关紧要了。
一些网站，如 Flickr，使用 API 密钥和密钥。密钥用于通过 MD5 哈希创建签名。服务器使用密钥计算相同的签名并以这种方式进行身份验证。秘密永远不需要通过网络。
于 2008-11-14T15:26:07.613 回答
7
GUID 是为了防止意外碰撞，而不是故意碰撞。换句话说，您不太可能猜出 GUID，但不一定很难找出您是否真的想猜。
于 2008-11-14T15:27:09.797 回答
2
起初我准备给出一个不合格的肯定，但这让我思考这是否意味着所有基于密码的身份验证都是默默无闻的安全性。在最严格的意义上，我认为它是，在某种程度上。
但是，假设您有用户使用密码登录并且您没有在任何地方发布该 GUID，我认为用户拥有的安全性较低的密码甚至 sysadmin 密码都超过了风险。
如果您说未受保护的管理页面的 URL 包含硬编码的 GUID，那么答案肯定是肯定的。
于 2008-11-14T15:29:11.697 回答
1
我同意大多数其他人的观点，它比弱密码更好，但最好使用更强大的东西，比如用于这种身份验证的证书交换（如果设备支持它）。
我还将确保您进行某种相互身份验证（即让设备验证服务器 SSL 证书以确保它是您期望的证书）。我很容易抓住设备，将其插入我的系统，并从中读取 GUID，然后将其重放回目标系统。
于 2008-11-14T16:30:19.730 回答
1
通常，如果您将密钥嵌入设备中，或者在身份验证期间传输密钥，则会引入安全漏洞。它们的密钥是 GUID 还是密码都没有关系，因为唯一的加密区别在于它们的长度和随机性。在任何一种情况下，攻击者都可以扫描您产品的内存或窃听身份验证过程。
您可以通过多种方式缓解这种情况，每种方式最终归结为增加密钥的模糊性（或保护级别）：
在存储之前加密密钥。当然，现在您需要存储该加密密钥，但是您已经引入了一定程度的间接性。
计算密钥，而不是存储它。现在，攻击者必须对您的算法进行逆向工程，而不是简单地搜索密钥。
在身份验证期间传输密钥的哈希值，而不是像其他人建议的那样传输密钥本身，或者使用质询-响应身份验证。这两种方法都可以防止密钥以明文形式传输。SSL 也可以做到这一点，但是你依赖于用户来维护一个正确的实现；你已经失去了对安全的控制。
与往常一样，无论何时解决安全问题，都需要考虑各种权衡。攻击的可能性有多大？如果攻击成功，会有什么风险？在开发、支持和可用性方面的安全成本是多少？
一个好的解决方案通常是一种折衷方案，可以令人满意地解决这些因素中的每一个。祝你好运！
于 2008-11-15T13:09:47.497 回答
0
我建议不要使用 GUID 作为密码（除了可能作为稍后更改的初始密码）。任何必须写下来才能记住的密码本质上都是不安全的。它会被写下来。
编辑： “固有地”是不准确的。在评论中查看对话
于 2008-11-14T15:24:57.337 回答
0
至少比使用“密码”作为密码要好。
我不认为 GUID 会被视为强密码，并且有许多强密码生成器可以像 Guid.NewGuid() 一样轻松使用。
于 2008-11-14T15:29:39.853 回答
0
这真的取决于你想做什么。使用 GUID 作为密码本身并不是通过晦涩难懂的安全性（但要注意一个事实，即 GUID 包含 128 个总数中的许多可猜测位：有一个时间戳，一些包括生成它的机器的 MAC 地址等）但真正的问题是您将如何存储该密码并将其传达给服务器。
如果密码存储在从未向最终用户显示的服务器端脚本中，则风险不大。如果密码嵌入到用户下载到自己机器的某个应用程序中，那么您将不得不在应用程序中混淆密码，并且没有办法安全地做到这一点。通过运行调试器，用户将始终能够访问密码。
于 2008-11-14T15:33:00.643 回答
0
当然，这是默默无闻的安全。但这很糟糕吗？任何“强”密码都是隐蔽的安全性。您指望身份验证系统是安全的，但最终，如果您的密码很容易被猜到，那么身份验证系统的好坏并不重要。因此，您制作了一个“强”和“晦涩”的密码以使其难以猜测。
于 2008-11-14T15:38:34.983 回答
0
它只是通过默默无闻的安全性，这就是密码的含义。使用 GUID 作为密码的主要问题可能是只使用字母和数字。但是，与大多数密码相比，GUID 相当长。对于详尽的搜索，没有密码是安全的；这很明显。仅仅因为 GUID 可能有也可能没有某种时间戳或 MAC 地址的某种基础，这在某种程度上是无关紧要的。
猜测它和其他东西的概率差异非常小。某些 GUID 可能比其他 GUID 更“容易”（阅读：更快）破解。越长越好。但是，字母表的多样性也更好。但同样，详尽的搜索揭示了一切。
于 2008-11-14T15:48:07.477 回答