Validate a localized $wp_default_secret_key

[nacin]

$wp_default_secret_key is designed to hold the default string for SECRET_KEY in wp-config-sample.php, which in en_US is 'put your unique phrase here'.

This is only used in wp_salt() (a pluggable function) to see if the key-holding constants in wp-config.php were changed.

But in a localized install, 'put your unique phrase here' is translated. Problem is, $wp_default_secret_key is defined in wp-settings.php (2.9) and the two localized installs I checked don't override it. (There are no translator instructions to do so.)

$wp_default_secret_key has since been moved to default-constants.php, where it is more out of place, since it cannot be overridden without hard-coding it there or or setting it much later. (No check is done to see if it is already set before setting the value.)

Security considerations:

In localized installs, $wp_default_secret_key never equals the default key, which means we treat a default string as if it were unique.

Possible ideas:

• Move $wp_default_secret_key to wp-includes/load.php (all strings that need to be hard-coded have been moved from wp-settings.php to there) and add a comment for translators / ensure that translators update the value.

• Probably outside the scope of this ticket, but we should have setup-config.php wp_remote_get('https://api.wordpress.org/secret-key/1.1/') and replace the default keys on install.

[nacin]

Ok, I'm now finding #5960. It seems the variable was created to begin with to allow localized installs to override it, but I can't find a localized install (I checked three) that overrides it.

Other related tickets:
#11664 - making it a constant ( which would affect a plugged in wp_salt() )[BR]]
#11379 - It looks like a plugin author was localizing it into his language.

[nacin]

Probably outside the scope of this ticket, but we should have setup-config.php wp_remote_get('​https://api.wordpress.org/secret-key/1.1/') and replace the default keys on install.

See #12159.

[westi]

Translators define the value of that constant in there lang_code.php file which we include after we set it to our default value.

e.g. ​http://svn.automattic.com/wordpress-i18n/bg_BG/trunk/dist/wp-content/languages/bg_BG.php

This is included after we call wp_cookie_constants() but before we use the pluggable functions I believe.

Translator instructions are here: ​http://codex.wordpress.org/Files_For_Direct_Translation#wp-config-sample.php

[nacin]

I didn't see that translator instruction, thanks.

I just looked through another dozen or so localizations and found maybe half that translated the string but did not include the translated value in their lang_code.php file.

There were three techniques employed that do work, but it shows that implementation of this is all over the map:

• Many do it properly, by translating the string and include the translated value in lang_code.php.
• Others leave it in English.
• At least one I found left it in English, and included a localized PHP comment. Here's de_DE:

  define('AUTH_KEY', 'put your unique phrase here'); // Trage hier eine beliebige, möglichst zufällige Phrase ein.
  

I've seen this posing problems before. de_DE uses the same technique as above for database defines, and thus do not translate those values in setup-config.php either. But from #11812, one team did translate the database defines, but did not translate the values in setup-config.php.

I think this is too widespread to mark this as invalid, but I'm not sure what we can do besides more education.

[westi]

I guess all we can do is see if we can create an automated tool to validate the I18N translation of files and then it can be used by the packaging script to report errors in the files.

[nacin]

Replying to westi:

I guess all we can do is see if we can create an automated tool to validate the I18N translation of files and then it can be used by the packaging script to report errors in the files.

Okay, shifting to wp.org and upping the priority, given that it poses a potential security risk.

[nbachiyski]

I am working on fixing that on the wordpress.org side.

[nbachiyski]

<locale>.wordpress.org sites build system now checks if the secret key provided in the translated wp-config-sample.php is the same as the key in wp-content/languages/<locale>.php and rejects the build if they are different.