如果您使用一个guid作为一个面向公众的应用程序的密码，作为获取服务访问权的一种手段，那么这种安全性是通过模糊来实现的吗？

我认为显而易见的答案是肯定的，但是我觉得安全级别很高，因为猜测guid的可能性很低，对吗？

更新

guid将存储在设备中，插入后将通过ssl连接通过guid发送。

也许我可以生成一个guid，然后在guid上执行aes 128位加密，并将该值存储在设备上？

在我看来，答案是否定的。

如果将密码设置为新创建的GUID，那么它是一个相当安全的密码：超过8个字符，包含数字、字母和特殊字符等。

当然，在guid中，'{'、'}'和'-'的位置是已知的，而且所有字母都是大写的。因此，只要没有人知道您使用的是guid，密码就很难破解。一旦攻击者知道他在寻找一个guid，暴力攻击所需的努力就会减少。从这个角度来看，这是一种默默无闻的安全。

不过，考虑一下这个guid:{91626979-FB5C-439A-BBA3-7715ED647504}，如果假设攻击者知道特殊字符的位置，那么他的问题就减少到查找字符串91626979FB5C439ABBA37715ED647504。强行输入32个字符的密码？只有在你有生之年，如果有人发明了一台可工作的量子计算机，这种情况才会发生。

这是通过使用一个非常，非常长的密码，而不是默默无闻来实现的安全性。

编辑：读完丹尼斯·亨尼西的答案后，我必须修改答案。如果guid确实以可解密的形式包含此信息(特别是mac地址)，攻击者可以大大减少密钥空间。在这种情况下，它肯定是安全的默默无闻，读：相当不安全。

当然，Musigenesis是正确的：有很多工具可以生成(伪)随机密码。我的建议是坚持其中之一。

实际上，使用一个guid作为密码不是一个好主意(相比之下，使用一个真正的长度相等的随机密码)。虽然它看起来很长，但实际上只有16个字节，通常包括用户的MAC地址、日期/时间和一个很小的随机元素。如果黑客可以确定用户的MAC地址，那么猜测他可能生成的guid就相对简单了。

如果可以观察到正在发送的guid(例如，通过http-auth)，那么它与猜测无关。

有些网站，如Flickr，使用API密钥和密钥。密钥用于通过MD5哈希创建签名。服务器使用密钥计算相同的签名，并以此方式进行身份验证。这个秘密不需要通过网络传播。

guid是为了防止意外碰撞，而不是故意碰撞。换句话说，你不太可能猜到一个guid，但不一定很难知道你是否真的想要。

起初，我准备给出一个无条件的"是"，但这让我想到，这是否意味着所有基于密码的身份验证都是模糊安全的。在某种程度上，我认为这是最严格的。

但是，假设您有用户使用密码登录，并且您没有在任何地方发布该guid，我认为用户使用的安全性较低的密码，甚至系统管理员密码都会使风险更大。

如果你说一个不受保护的管理页面的URL包含一个硬编码的guid，那么答案肯定是肯定的。

通常，如果您将密钥嵌入到设备中，或者在身份验证期间传输密钥，则会引入安全漏洞。它们的密钥是一个guid还是一个密码并不重要，因为唯一的密码区别在于它们的长度和随机性。无论哪种情况，攻击者都可以扫描产品的内存或窃听认证过程。

您可以通过几种方式来缓解这种情况，每种方式最终归结为增加密钥的模糊性(或保护级别)：

• 在存储密钥之前对其进行加密。当然，现在您需要存储该加密密钥，但是您已经引入了一个间接级别。

• 计算键，而不是存储它。现在，攻击者必须对您的算法进行反向工程，而不是简单地搜索密钥。

• 按照其他人的建议，在身份验证期间传输密钥的哈希，而不是密钥本身，或者使用质询响应身份验证。这两种方法都防止密钥以明文形式传输。ssl也可以做到这一点，但是您依赖用户来维护适当的实现；您已经失去了对安全性的控制。

和往常一样，无论何时处理安全问题，都需要考虑各种权衡。攻击的可能性有多大？如果攻击成功，风险是什么？在开发、支持和可用性方面，安全性的成本是多少？

一个好的解决方案通常是一个折衷方案，能够令人满意地解决这些因素中的每一个。祝你好运！

我同意大多数人的看法，它比弱密码更好，但最好使用更强大的东西，如用于这种身份验证的证书交换(如果设备支持)。

我还将确保您执行某种类型的相互身份验证(即让设备验证服务器的SSL证书，以确保它是您期望的证书)。我可以很容易地抓取这个设备，将它插入我的系统，读取它的guid，然后将其重放回目标系统。

它只是通过模糊来保证安全，在某种程度上，这就是密码。使用guid作为密码的主要问题可能是只使用字母和数字。但是，与大多数密码相比，guid相当长。完全搜索没有安全的密码；这很明显。仅仅因为一个guid可能或可能没有基于某种时间戳的基础，或者也许一个mac地址是不相关的。

猜测它和其他东西的概率差异非常小。有些guid可能比其他guid更容易被破坏(读：快)。越长越好。然而，字母表的多样性也更好。但同样，详尽的搜索揭示了一切。

当然，这是默默无闻的安全。但这不好吗？任何"强"密码都是暗箱操作的安全密码。你指望认证系统是安全的，但最终如果你的密码是容易猜测的，那么认证系统有多好并不重要。所以你要做一个"强"和"模糊"的密码，使它很难猜测。

这真的取决于你想做什么。使用一个guid作为密码本身并不安全(但是要注意，guid包含128个总数中的许多可猜测位：有一个时间戳，其中一些包括生成它的机器的MAC地址等)，但真正的问题是如何存储密码并将其与服务器通信。

如果密码存储在从未向最终用户显示的服务器端脚本上，则没有太大的风险。如果用户下载到自己的计算机上的某个应用程序中嵌入了密码，那么您将不得不混淆该应用程序中的密码，并且无法安全地执行该操作。通过运行调试器，用户将始终能够访问密码。

至少比用"密码"作为密码要好。

我不认为一个guid会被认为是一个强大的密码，有很多强大的密码生成器，您可以像guid.newguid()一样轻松地使用。

我建议不要使用guid作为密码(除了最初的密码，以后可能会更改)。必须记下才能记住的任何密码都是固有的不安全的。它会被写下来。

编辑："固有"不准确。查看评论中的对话