Make WordPress Core

Opened 13 years ago

Closed 12 years ago

#16623 closed defect (bug) (invalid)

Authentication Unique Keys and Salts broke wp-config.

Reported by: christopherross's profile christopherross Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.0
Component: Site Keywords:
Focuses: Cc:

Description (last modified by dd32)

I've never seen this happen before but today I was installing WordPress and the Authentication Unique Keys and Salts broke the site during install.

define('NONCE_SALT', 'J6:6$c."Eec\_WQ:B2V \h 3,WZ?q<O[uTYq_~(@+[^T@}M,}yq6JKT3)PgKqRd\');

I've attached a Dreamweaver screenshot where the code highlighter found the error, after replacing the J6:6$c."Eec\_WQ:B2V \h 3,WZ?q<O[uTYq_~(@+[^T@}M,}yq6JKT3)PgKqRd\ above with a clean salt, it worked again.

Attachments (1)

Screen shot 2011-02-23 at 7.11.03 PM.png (80.4 KB) - added by christopherross 13 years ago.
Screenshot of error in text editor

Download all attachments as: .zip

Change History (8)

13 years ago

Screenshot of error in text editor

#1 @dd32
13 years ago

  • Component changed from Upgrade/Install to site
  • Description modified (diff)
  • Milestone changed from Awaiting Review to

Moving to - can be moved back for 3.2 after API change is done perhaps

The API is returning a slash at the end of the string, whilst that's legit, core doesn't escape the string, and appears to be using it as-is. The result is the closing quote is escaped, causing.. well.. what you've got there

#2 @dd32
13 years ago

Upon some more checking.. The API shouldn't be returning slashes at all, or " both of which are in your keys..

You used the web-creation of wp-config.php correct? and WordPress 3.1 just did it all by itself? (Or did you manually create the config file, OR copy-paste the file contents it gave you?)

#3 @Otto42
13 years ago

Yes, after several runs, I can't get the secret key generator on .org to return any slashes at all, much less at the end of the string:

Does core generate its own instead of hitting the API?

#4 @sivel
13 years ago

During the install, if wp_remote_get cannot fetch the keys, it will fall back to using wp_generate_password:

wp_generate_password( 64, true, true );

wp_generate_password() does not however, generate backslashes (\). Possible characters are:

-_ []{}<>~`+=,.;:/?|

When I initially wrote the patch to add in the extra chars for this specific use I ran 100 tests against the APIs to find what characters it used, which is where this list has come from. But as mentioned it does not include any backslashes as shown in this bug report.

Are mu-plugins included during the install process, if they exist? Would be strange to have one there before install, but it may be possible for wp_generate_password() to be override since it is in pluggable.php.

#5 @aaroncampbell
13 years ago

It also uses wp_generate_password id noapi is set. However, wp_generate_password doesn't allow for backslashes, and I just ran a quick test by fetching 1000 times and got no backslashes there either.

#6 @Otto42
13 years ago

The API call actively replaces backslashes with pluses. It can't return them in the keys.

#7 @nacin
12 years ago

  • Milestone deleted
  • Resolution set to invalid
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.