是否使用GUID安全性虽然默默无闻？

Question

如果您使用GUID作为面向公众的应用程序的密码作为获取服务访问权的手段，这种安全性是否通过默默无闻？

我认为明显的答案是肯定的，但是对我来说安全级别似乎很高，因为猜测GUID的可能性非常低是正确的吗？

更新

GUID将存储在设备中，当插入时，将通过SSL连接通过GUID发送。

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

Answer 1

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

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

当然，在GUID中，'{'，'}'和'-'的位置是已知的，并且所有字母都是大写的。因此，只要没有人知道您使用GUID，密码就更难破解。一旦攻击者知道他正在寻找GUID，蛮力攻击所需的努力就会减少。从这个角度来看，它是安全隐藏。

仍然，请考虑此GUID：{91626979-FB5C-439A-BBA3-7715ED647504}如果您认为攻击者知道特殊字符的位置，则他的问题将减少为查找字符串91626979FB5C439ABBA37715ED647504。暴力迫使32个字符的密码？如果有人发明了一台有效的量子计算机，它只会发生在你的一生中。

这是安全性，使用非常长的密码，而不是 by obscurity 。

修改 看完丹尼斯轩尼诗的答案后，我不得不修改答案。如果GUID确实以可解密的形式包含此信息（特别是mac地址），则攻击者可以大大减少密钥空间。在这种情况下，肯定是安全隐藏，阅读：相当不安全。

当然，MusiGenesis是对的：有很多工具可以生成（伪）随机密码。我的建议是坚持其中一个。

Answer 2

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

Answer 3

如果可以观察到正在发送的GUID（例如通过HTTP Auth），那么它的可猜测性就无关紧要了。

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

Answer 4

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

Answer 5

起初我准备给出一个不合格的是，但它让我想到这是否意味着所有基于密码的身份验证都是默默无闻的安全性。从最严格的意义上来说，我认为它在某种程度上是存在的。

但是，如果您让用户使用密码登录并且您没有在任何地方发布该GUID，我认为用户拥有的安全性较低的密码甚至是sysadmin密码都会超过风险。

如果你说过一个没有受到其他保护的管理页面的URL包含一个硬编码的GUID，那么答案肯定是肯定的。

Answer 6

我同意大多数其他人的说法，它比弱密码更好，但最好使用更强大的东西，例如用于此类身份验证的证书交换（如果设备支持它）。

我还会确保您进行某种相互身份验证（即让设备验证服务器SSL证书以确保它是您期望的那种）。我很容易抓住设备，将其插入我的系统，并从中读取GUID，然后将其重播回目标系统。

Answer 7

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

您可以通过多种方式缓解这种情况，每种方式最终归结为增加密钥的隐匿性（或保护级别）：

• 在存储密钥之前加密密钥。当然，现在你需要存储那个加密密钥，但是你引入了一个间接级别。

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

• 在身份验证期间传输密钥的哈希，而不是其他人建议的密钥本身，或使用质询 - 响应身份验证。这两种方法都阻止密钥以明文传输。 SSL也可以实现这一目标，但是你依赖于用户来维持正确的实现;你已经失去了对安全的控制。

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

一个好的解决方案通常是妥协，可以令人满意地解决这些因素。祝你好运！

Answer 8

我建议不要使用GUID作为密码（除非可能是以后要更改的初始密码）。任何必须记下来记住的密码都是本身不安全。它会写下来。

修改：“内在”不准确。看评论中的对话

Answer 9

最好比使用“密码”作为密码更好。

我认为GUID不会被认为是一个强密码，并且有许多强大的密码生成器可以像Guid.NewGuid（）一样轻松使用。

Answer 10

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

如果密码存储在从未向最终用户显示的服务器端脚本中，则风险不大。如果密码嵌入在用户下载到其​​自己的计算机的某个应用程序中，则您必须在应用程序中对密码进行模糊处理，并且无法安全地执行此操作。通过运行调试器，用户将始终能够访问密码。

Answer 11

当然，默默无闻是安全。但这不好吗？任何“强大”的密码都是默默无闻的安全性。您指望认证系统是安全的，但最后如果您的密码很容易猜到，那么认证系统的好坏并不重要。因此，您需要制作一个“强大”和“模糊”的密码，以便难以猜测。

Answer 12

这只是通过默默无闻的安全性，这就是密码的含义。使用GUID作为密码的主要问题可能是只使用字母和数字。但是，与大多数密码相比，GUID相当长。没有密码可以安全地进行详尽的搜索;这很明显。仅仅因为GUID可能会或可能没有某种时间戳的某些基础，或者可能是MAC地址有点无关紧要。

猜测它和其他东西的概率差异非常小。一些GUID可能“更容易”（读取：更快）以打破其他人。越长越好。但是，字母表中的多样性也更好。但同样，详尽的搜索揭示了所有。