WordPress.org

Make WordPress Core

Opened 11 years ago

Closed 11 years ago

Last modified 10 years ago

#8647 closed enhancement (fixed)

Try to configure secure keys in wp-config.php on install

Reported by: sivel Owned by: westi
Milestone: 2.8 Priority: normal
Severity: normal Version: 2.7
Component: General Keywords: has-patch dev-reviewed
Focuses: Cc:

Description

From what I have seen, many people install WordPress and never configure the secure keys in wp-config.php. For security purposes this should be done. We should either let the user know to do so after the install or at least try to do it for them.

The attached patch will try to get the secure keys from the secure-keys api and if successful place them in wp-config.php. If unsuccessful it will inform the user to do so after the install is finished.

Attachments (5)

setup-config-php-secure-keys.diff (2.4 KB) - added by sivel 11 years ago.
setup-config-php-secure-keys.2.diff (1.5 KB) - added by sivel 11 years ago.
Use wp_generate_password instead of the api
wp_generate_password.diff (688 bytes) - added by sivel 11 years ago.
Modified to include $extra_special_characters argument with additional special characters
pluggable-php.diff (1.6 KB) - added by sivel 11 years ago.
Modified wp_generate_password and updates to wp_salt to use 64 character special and additional special characters for secret-keys.
wp_salt.diff (1.1 KB) - added by sivel 11 years ago.
Or at least update wp_salt to use 64 characters generated by the standard wp_generate_password.

Download all attachments as: .zip

Change History (17)

#1 follow-up: @jacobsantos
11 years ago

Why not attempt to create the key yourself if the response fails. Some will NOT want to have the keys over HTTP connection. HTTPS might be only a tiny bit better. Giving them the option might also be better, but that would add an additional step.

#2 in reply to: ↑ 1 @sivel
11 years ago

Replying to jacobsantos:

Why not attempt to create the key yourself if the response fails.

Isn't that what I said and what the patch does? If the response fails the user is informed to create the keys themselves.

Some will NOT want to have the keys over HTTP connection. HTTPS might be only a tiny bit better.

The patch is configured to use the HTTPS url and not the HTTP url. Since wp-config.php lists the url to the secret-keys api as the recommended way to generate these secret keys how is it any less secure than the user requesting that page and then pasting it into their file? Most users use FTP anyway so they would have just requested the api using https in their browser and then used plain text ftp to upload their secret keys, which is less secure than the install handling it.

#3 follow-up: @jacobsantos
11 years ago

No, I mean create the random key and insert it yourself. Don't tell the user that they should do, because you don't really solve anything. It is completely possible to create a random key 64 characters long that is similar to the API key.

#4 in reply to: ↑ 3 @sivel
11 years ago

Replying to jacobsantos:

No, I mean create the random key and insert it yourself. Don't tell the user that they should do, because you don't really solve anything. It is completely possible to create a random key 64 characters long that is similar to the API key.

In that case we could skip the API all together. Perhaps someone can duplicate the API functionality into core. I'd rather use the same code the API does rather than write a new function.

#5 @mrmist
11 years ago

-1 to introducing another external entity.

I could bet that the people who won't have the secret keys will be exactly the sort that are on quirky hosting set-ups that make the API requests bomb out in spectacular ways.

Suggest that if this is implemented, that there's a wp-config define that can be used to turn it off for support/debug reasons. In fact I'd like that for all the external requests. ho-hum.

@sivel
11 years ago

Use wp_generate_password instead of the api

@sivel
11 years ago

Modified to include $extra_special_characters argument with additional special characters

#6 @sivel
11 years ago

Here is another idea. Modify wp_generate_password to include an additional parameter ($extra_special_chars) to add the additional special characters used by the API.

Use wp_generate_password to generate the 64 char random string for the the secret keys. Although I don't really like the added complexities of trying to include pluggable.php to get use of wp_generate_password.

Another option is to leave things as it is. wp_salt will add an option to the options table containing a 12 character key for each of the 4 values ou would normally configure in wp-config.php. We could always update wp_salt to use the wp_generate_password function updates attched to this ticket.

@sivel
11 years ago

Modified wp_generate_password and updates to wp_salt to use 64 character special and additional special characters for secret-keys.

@sivel
11 years ago

Or at least update wp_salt to use 64 characters generated by the standard wp_generate_password.

#7 @sivel
11 years ago

  • Keywords has-patch added

Would anyone else like to comment on the changes proposed in this ticket?

#8 @westi
11 years ago

  • Keywords dev-reviewed added
  • Owner changed from has-patch to westi
  • Status changed from new to assigned

Looks good.
Putting on personal patch review queue

#9 @westi
11 years ago

Think we stick with just extending to 64 chars for now.

#10 @westi
11 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

(In [10577]) If we have to generate people salts then make them 64 chars long. Fixes #8647 props sivel.

#11 @jidanni
11 years ago

All I know is there should be no need to go out on the network to
generate random strings.

The wording in 2.7.1's wp-config-sample.php almost makes it seem there is no other way.

#12 @nacin
10 years ago

Related: #12159

Note: See TracTickets for help on using tickets.