为什么WordPress安装在安装时远程检索密码秘密？

Question

看来WordPress 远程检索所有密码常量。 (通过HTTPS)：

// setup-config.php
$secret_keys = wp_remote_get( 'https://api.wordpress.org/secret-key/1.1/salt/' );

• 这样做有什么好处，而不是在本地生成密钥？
• 这完全没有必要吗？它只会为WordPress设置提供另一个攻击矢量吗？

Answer 1

这可以说是糟糕的设计，但我们可以理解设计是从哪里来的。

它可以说是糟糕的设计，因为它依赖于api.wordpress.org来生成随机密钥并将它们保密。如果api.wordpress.org被破坏，那么攻击者可以安排记录新的Wordpress安装所使用的密钥。这是有问题的。

(是的，Wordpress可以向您发送反向源代码，但原则上，任何检查源代码的人都可以检测到--就像您所做的那样。)相反，如果api.wordpress.org正在秘密地记录它发送给新Wordpress安装的密钥副本，那么任何数量的源代码检查或感兴趣的第三方可用的任何其他机制都无法检测到)。

这是可以理解的，因为很难以平台无关的方式产生密码质量的随机性。

它仍然可以说是有点草率/懒惰。可以说，更好的设计是收集局部随机性(如果可能的话)，从api.wordpress.org收集一些随机性，然后使用加密散列函数安全地混合两者。这样，只要这两个值中的任何一个都是好的，您就会很安全。api.wordpress.org的妥协不会危及在代码能够收集一些本地随机性的平台上运行的Wordpress安装；它只会危及少数无法获得良好随机性的安装。

如何从本地来源产生良好的加密质量的随机性？有多种方式：

• 从/dev/urandom读取16个字节(如果存在的话)。
• 打电话给openssl_random_pseudo_bytes()，哪个调用OpenSSL来获得加密质量的伪随机比特.。
• 使用mcrypt_create_iv()标志调用MCRYPT_DEV_URANDOM。
• 当然，你可以尝试所有可用的选项，并将你得到的所有东西混合在一起。只要这些选项中至少有一个有效，你就会很好。当然，如果您将它与使用加密函数的api.wordpress.org输出混合在一起，它将永远不会比今天的方法更糟糕，而且如果api.wordpress.org被破坏，情况也会更好。

因此，将局部随机性和远程随机性结合起来是一种更好的方法。不幸的是，这确实需要更多的工作和更多的代码。也许开发人员采用了一种简单的方法，只查询api.wordpress.org。人们可以讨论这个设计决策，但是您可以理解这种方法是如何被选择的。

不过，总的来说，正如Thomas所说，这可能不是Wordpress面临的最大安全风险。我们讨论的是具有长期安全漏洞的软件。因此，与你已经承担的风险相比，随机数产生的这一方面增加的风险可能很小。

有关从PHP中的安全随机数生成生成密码质量随机数的更多信息，请参见在密码解决方案中使用来自random.org的随机数安全吗？，更多关于为什么依赖远程随机数字源作为密码密钥不是一个好主意的更多信息。

Answer 2

同样的原因，它的非常困难可以生成您自己的熵，特别是在云或共享托管环境中。

本质上，WordPress是说它们比你有更多的熵。他们可能是对的！所以他们产生并返回它。

这是一个可能的攻击媒介。但是，我不认为这是可能的，因为如果它是目标，攻击者需要控制您的网络，以便将DNS调用重定向到适当的服务器。然后，他们需要伪造SSL证书。总之，极不可能。