这可以说是糟糕的设计，但可以理解设计的来源。

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

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

这是可以理解的，因为很难以独立于平台的方式生成加密质量的随机性。

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

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

• 从 中读取 16 个字节/dev/urandom（如果存在）。

• Call openssl_random_pseudo_bytes()，它调用 OpenSSL 以获取加密质量的伪随机位。

• 呼叫mcrypt_create_iv()，与MCRYPT_DEV_URANDOM旗帜。

• 当然，您可以尝试所有可用的选项并将您获得的所有内容混合在一起。只要这些选项中的至少一个有效，你就会很好。当然，如果你将它与api.wordpress.org使用加密函数的输出混合在一起，它永远不会比今天的方法更糟糕，而且如果api.wordpress.org受到损害会更好。

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

不过，总体而言，正如 Thomas Pornin 所言，这可能不是 Wordpress 最大的安全风险。我们谈论的是具有长期安全漏洞历史的软件。因此，与您已经采取的任何一种方式的风险相比，随机数生成的这一方面所增加的风险可能很小。

有关从 PHP 生成加密质量随机数的更多信息，另请参阅PHP 中的安全随机数生成，以及在加密解决方案中使用 random.org 中的随机数是否安全？了解更多关于为什么依赖远程随机数源获取加密密钥不是一个好主意的信息。

同样的原因，很难生成自己的熵，尤其是在云或共享托管环境中。

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

这是一个可能的攻击媒介。但是，我认为这不太可能，因为如果它是有针对性的，攻击者需要已经控制您的网络才能将 DNS 调用重定向到正确的服务器。然后，他们需要伪造 SSL 证书。总而言之，极不可能。

网址是：https://api.wordpress.org/secret-key/1.1/salt/

因此，它使用 SSL。即使攻击者破坏 DNS 以重定向该调用，他们仍然必须以某种方式拥有包含该api.wordpress.org名称的有效服务器证书。因此，攻击者可能很难运行伪造的密钥生成服务器。

当然，WordPress 服务器本身将能够记录它生成的所有密钥，并背叛你。但是请注意，他们已经可以通过在他们的软件中插入后门来做到这一点——您使用的（他们甚至可能将后门称为“漏洞”并合理地声称他们不是故意这样做的）。从这个意义上说，您已经信任了 WordPress 人；有了这个服务器端密钥生成的东西，你就继续信任他们。就我个人而言，我不会太担心它（至少，不像使用基于 PHP 的框架的事实那么担心，该框架具有悠久的安全问题历史）。

正如@jrg 指出的那样，在某些基于云的环境中安全地生成密钥可能具有挑战性：计算机通过测量硬件的物理事件来获得随机性；在虚拟机中没有要测量的实际硬件。具体来说，一些云提供商通过使用 VM 快照来实例化机器。因此，从一个公共快照发出的所有机器共享相同的初始状态，尤其是任何随机种子。使用服务器端密钥生成可以避免这个问题。