It seems that WordPress retrieves all the crypto constants remotely (via HTTPS):

// setup-config.php
$secret_keys = wp_remote_get( 'https://api.wordpress.org/secret-key/1.1/salt/' );
  • Are there any benefits to doing this instead of generating the keys locally?
  • Is this completely unnecessary? Will it only provide another attack vector to WordPress setups?
  • Great material for a conspiracy theory. :)
    – ndrix
    Jun 23, 2014 at 9:06
  • I opened #35290 to address this design flaw and promote more-secure-by-default practices. Jan 2, 2016 at 23:09

3 Answers 3


This is arguably bad design, but one can understand where the design came from.

It is arguably bad design, because it relies upon api.wordpress.org to generate random keys and keep them secret. If api.wordpress.org gets compromised, then the attackers could arrange to record the keys that are used by new Wordpress installations. That would be problematic.

(Yes, Wordpress could send you backdoored source code, but that would be detectable in principle by anyone who examines the source code -- as you have done. In contrast, if api.wordpress.org is secretly recording a copy of the keys it sends to new Wordpress installations, that is not detectable by any amount of source code inspection or any other mechanism available to interested third parties.)

It is understandable, because it is hard to generate crypto-quality randomness in a platform-independent way.

It's still arguably a bit sloppy/lazy. Arguably, a better design would have been to gather some local randomness (if possible), gather some randomness from api.wordpress.org, and then mix the two securely using a cryptographic hash function. That way, you'll be secure as long as either of those two values is good. A compromise of api.wordpress.org would not endanger Wordpress installations running on any platform where the code was able to gather some local randomness; it would only endanger the small minority of installations that were unable to get good randomness.

How can one generate good crypto-quality randomness, from local sources? There are various ways:

  • Read 16 bytes from /dev/urandom, if it exists.

  • Call openssl_random_pseudo_bytes(), which invokes OpenSSL to get crypto-quality pseudorandom bits.

  • Call mcrypt_create_iv(), with the MCRYPT_DEV_URANDOM flag.

  • Of course, one can try all available options and mix together everything you get. As long as at least one of these options work, you'll be good. And of course, if you mix this together with output from api.wordpress.org using a cryptographic function, it'll never be any worse than today's approach, and will be better if api.wordpress.org ever gets compromised.

So, combining local and remote randomness would have been a better approach. Unfortunately, that does require a bit more work and a bit more code. Perhaps the developers took the easier approach of just querying api.wordpress.org. One could debate that design decision, but you can understand how this approach might have been chosen.

Overall, though, as Thomas Pornin argues, this is probably not the biggest security risk with Wordpress. We're talking about software with a long history of security vulnerabilities. So, the incremental risk added by this aspect of their random-number generation might be small, compared to the risk you're already taking either way.

See also Secure random number generation in PHP for more on generating crypto-quality random numbers from PHP, and Would it be secure to use random numbers from random.org in a cryptographic solution? for more on why it is not a great idea to rely upon a remote source of random numbers for your crypto keys.

  • 1
    Follow-up: PHP 7 offers random_bytes() and I helped write a polyfill for PHP 5.x which landed in WordPress 4.4. Jan 2, 2016 at 22:20

Same reason its very difficult to generate your own entropy, particularly in a cloud or shared hosting environment.

Essentially, WordPress is saying that they have more entropy than you do. They are probably right! So they generate it and return it.

It is a possible attack vector. However, I don't think its likely, because if it's targeted, the attacker needs to be in control of your network already to redirect the DNS call to the proper server. THEN, they need to fake a SSL certificate. All told, highly unlikely.

  • 5
    An attacker could hack the server providing entropy to provide "less random" output, which would be close to undetectable, but would weaken security for all new installations. I am fairly sure one could come up with an all-caps name for such an endeavor. Jun 23, 2014 at 17:12
  • 6
    Right. If api.wordpress.org is hacked, the hackers don't even need to provide less-random output; they could just record a copy of all the random numbers provided to anyone, leaving new installations screwed. It would be basically impossible for anyone other than Wordpress admins to detect such an attack.
    – D.W.
    Jun 23, 2014 at 20:39
  • 5
    It seems like WordPress should mix entropy from api.wordpress.com and a local source. Then an attack on api.wordpress.org could only compromise servers which had low entropy, rather than all servers. Jun 24, 2014 at 1:35

The URL is: https://api.wordpress.org/secret-key/1.1/salt/

Thus, it uses SSL. Even if attackers subvert the DNS to redirect that call, they would still have to somehow own a valid server certificate containing the api.wordpress.org name. As such, it is probably difficult for attackers to run a fake key generating server.

Of course, the WordPress server itself would be able to record all keys that it generated, and betray you. Note, though, that they can already do that by inserting backdoors in their software -- that you use (they may even call backdoors "vulnerabilities" and plausibly claim that they did not do it on purpose). In that sense, you are already trusting the WordPress people; with this server-side key generation thing, you just keep on trusting them. Personally I would not worry too much about it (at least, not as much as the mere fact of using a PHP-based framework with a long history of questionable security).

As @jrg points out, generating keys securely can be challenging in some cloud-based environments: a computer gets randomness by measuring physical events from the hardware; in a virtual machine there is no actual hardware to measure. Specifically, some cloud providers instantiate machines by using VM snapshots. All machines issuing from a common snapshot thus share the same initial state, in particular any random seed. Using server-side key generation avoids that issue.

  • 8
    I don't fully buy the comparison to backdoors in the source code. There is an important difference: if the source code is backdoored, there is at least the potential for detecting the backdoor by inspecting the source code; whereas if api.wordpress.org is hacked and the attackers record a copy of all random numbers it ever provides, there is no way (even in principle) for third parties to detect that. So I don't think this risk is 100% equivalent to that of backdoors in the source code. I do agree with your bottom line that, in the end, this isn't the biggest worry about Wordpress.
    – D.W.
    Jun 23, 2014 at 20:41
  • 3
    Well, maybe this is one of those "plausibly deniable" backdoors! Jun 24, 2014 at 2:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .