WordPress 3.0 Thelonious Security Features

WordPress 3.0 TheloniousAfter much anticipation, the stable version of WordPress 3.0 (Thelonious) was released on Thursday, June 17, 2010.

According to Matt Mullenweg, WordPress 3.0 is faster, stabler and more secure. It comes with more than 1,200 bug fixes and feature enhancements.

After reviewing the comprehensive list of improvements available at the 3.0’s Codex page, here’s my review of some security features or concerns:

  • New default theme, “Twenty Ten.” I plan on checking out this theme more thoroughly and will update you about any security concerns.
  • WordPress and WordPress MU have merged, allowing the management of multiple sites (called Multisite) from one WordPress installation. Although, this is a great feature for those that want to have multiple sites in one, please be careful. If you allow others to create a blog within your blog, it becomes more of a security risk when you allow end users certain permissions.
  • Ability to set the admin username and password during installation. I am really excited about this feature. Finally, we don’t have to manually change or delete the “admin” user. Be sure you use a strong username and password.
  • Check required php and mysql versions in the update and notify if the server environment does not meet those requirements. This will help with compatibility issues.
  • Block comments for future posts and password protected posts (when password not provided). Nice feature.
  • Upgrade plugins in bulk from the Plugins > Installed panel. I am a bit concerned with this. If one of the plugins you’re upgrading is incompatible and it breaks your site, how will you know which plugin caused the problem without manually deactivating them one at a time?
  • When deleting plugins, check for uninstall hooks and ward of data deletion. Nice feature.
  • Allow “No role for this blog” to be chosen in Users > Add New panel. Nice feature.
  • Automatic generation of Security Keys during installation. Wow! I’m really glad to hear this. Most newbies never even add these and now it will be done for them.
  • Validate table_prefix in wp-config.php generator. I am going to try a fresh install in a test site and see if it allows me to choose my own table prefix. Not using the default table prefix “wp_” helps keep out hackers.
  • Reminder to plugin authors to test and make sure they do not generate unexpected output; see Ryan Boren’s explanation. Nice. During plugin activation, WP 3.0 check to see if the plugin generates any output. If any output is generated, a warning is shown to the user.
  • Updates to jQuery, jQuery UI, json lib, phpass, Prototype.js, Scriptaculous.js, and SWFobject JS. Glad to see those are current now!

I’m really excited about all the new features and security enhancements WordPress 3.0 has to offer. However, because this was such a huge overhaul of WordPress, I am going to install a test site and import my theme, plugins and data to see if all works well before I update my production website.

We encourage you to upgrade your WordPress to the latest stable version (3.0) as well. You can download it or upgrade within your dashboard.

Be sure to watch the WordPress 3.0 video tour below:

Update 6/18/2010 at 1:30pm: Currently, I am not finding any historic plugin compatibility data for WordPress 3.0, but will keep an eye on this article for any future info.

Thanks to Petrus4, the WP Events Calendar plugin has an issue. See http://www.wp-eventscalendar.com/ and http://wordpress.org/support/topic/409138.

Regarding themes, I also do not see any historic lists of compatible themes yet, but will watch that one also.

Update 6/25/2010 at 2:00 pm: Be sure to check out the sticky post called “3.0 Issues, Problems, Resolutions Thread” at WordPress.org.

We’d like to hear from you…

Have you tried WordPress 3.0 yet? Noticed any new security features I didn’t mention above? Be sure to share your WordPress 3.0 experience by leaving a comment below.

Securely yours,

Regina Smola
Follow me on Twitter
Follow WPSecurityLock on Twitter

Comments

    • says

      Hi Eyal,

      Thanks for your comment. Nice article for those that know SSH. I did a quick review of your post and have a question. Why do you call the following command?

      define(‘FS_CHMOD_DIR’, 0777);
      define(‘FS_CHMOD_FILE’, 0777);
      chmod -R 777 /www/wordpress/wp-content/cache
      chmod -R 777 /www/wordpress/wp-content/uploads
      chmod -R 777 /www/wordpress/wp-content/upgrade
      chmod 777 /www/wordpress/wp-content/backup-ed602

      I don’t suggest or use 777 for any directory.

      • punkin says

        If the resident web server isn’t doing suexec, then it will be writing to these directories as the default web server user (e.g., “nobody”), rather than as the owner user. Making those directories world-writable is sometimes the only way a non-root user can allow the web server to write to the file system. Obviously, this is less than ideal, and shouldn’t be done without understanding the risks.

        • says

          I hear ya, but I would NOT set anything to 777, regardless of what my web server uses. My solution: If your host doesn’t use suexec and you have to use 777, change hosts IMMEDIATELY. This is way to big of a risk for anyone.

          • nomalab says

            Or contact your host and ask them to chown those directories to www-data, nobody or what ever user the web server is being run as. Good hosts do this for free and within 10 minutes.

      • says

        1. My article is trying to show the most secure configuration and keep best practices for configuring WordPress – I gave an easy instructions for using SSH keys, so everyone could perform, even if they are not familiar with the process

        2. According to the article http://www.viper007bond.com/2009/05/07/wordpress-how-to-force-direct-filewrites-for-upgrades – “The permissions need to be 0777 (or similar) so that you can still modify the files/folders if need be”.

        3. According to the article http://codex.wordpress.org/Changing_File_Permissions – “Some plugins require the /wp-content/ folder be made writeable, but in such cases they will let you know during installation. In some cases, this may require assigning 755 permissions or higher (e.g. 777 on some hosts). The same is true for /wp-content/cache/ and maybe /wp-content/uploads/”.

        4. According to the article http://wordpress.org/support/topic/283232 – permission 777 is required for the /wp-content/upgrade in-order to complete an upgrade between WordPress versions (even if only on temporary basis).

        5. The plug-in “WordPress Database Backup” (http://austinmatzko.com/wordpress-plugins/wp-db-backup), will not work without setting permission 777 on the folder /wp-content/backup-ed602

    • says

      Sorry, I just can’t respect an article about WordPress hosted on Blogspot!

      As for plugin upgrades, in 3.0 it says the plugin compatibility right under the upgrade notice.

      • says

        Hi Matt,

        I’m glad to hear that the plugin compatibility is built inside of the upgrade notice. I have several websites to upgrade and I can’t wait to get them running on WordPress 3.0.

  1. says

    Nice overview Regina,

    I took a dive and upgraded few of my blogs including main one to new version. There are some compatibility issues with plugins – be sure to check yours. I also seen at least one plugin cause severe slow down of blog and generally – blog becomes slower loading even with small number of plugins.

    I know dev team promised us speed – but I don’t personally see it being delivered. A bit dissapointing

    • says

      Hi Alex,

      Thanks for your comment. Glad to see you got to try it out already.

      Yes, current plugins and themes seem to be of concern for many. I am going to check each plugin via http://wordpress.org/extend/plugins/ and see if they are compatible and read what others are saying about them before I try the upgrade on my main site.

      I use StudioPress themes and need to check them also to see if my current themes will work and my Digital Access Pass too.

      Sorry to hear that speed is an issue. Have you done any debugging to see what may be causing it?

      I certainly want to take advantage of the security enhancements and upgrade as soon as possible. I am going to install on a test site this weekend.

    • Harriman Real Estate says

      Alex, what are the specific plug-ins that you have seen issues with in WP 3.0? Any common ones that everyone uses? Thanks!

  2. Shirley says

    Hi Regina!

    I love your site and have learned so much about WP security. Thank you!

    I updated to WP 3.0 so far so good. I like a lot of the new features.

    I’m not a web person so this may be common sense for most but after updating all of my sites I noticed that WP-Security Scannner (love this plug in) warned me that my “root directory” permissions had been changed from 755 to 750 So I went ahead and changed the permissions back to 755 as it suggested.

    Can you explain in layman’s terms why WP 3.0 causes this change? And if I had not had WP Security Scanner already installed would I have any way of knowing this should be changed?

    Thanks and keep up the great work!

    Shirley

    • says

      Hi Shirley,

      Thanks for your wonderful comment and question.

      I’m glad to hear that WP 3.0 is working for you. Yes, the new features our outstanding! The developers did a fantastic job. I am so grateful that they allow us to use this wonderful platform and keep enhancing it for us.

      Regarding your 750 permission issue, sometimes hosting companies use 750 or 705 as their default setting on directories. I know that the default for GoDaddy shared hosting is 705 and have seen that message in the WP Security Scan plugin.

      I contacted the Security Team at GoDaddy and this is what they said:

      “All of our users are placed in the ‘inetuser’ group. That is the basis for why we set the empty group bit (eg: 705, 604 .. instead of 755 and 644). The apache user is NOT in the ‘inetuser’ group so it can read any of your files that have the ‘other’ permission set, while other users CANNOT read your files or directories because the group set on the files is ‘inetuser’ but the group bit is 0’d out.

      It generally should not matter whether files within your home dir are 604 versus 644 (or 705 versus 755) because your home directory itself ($HOME) is 705 and owned by the ‘inetuser’ group. This prevents other users from reading any files below your homedir, which is the main point of our permission scheme.”

      My translation: As far as being the end-user (you), there really is no difference between 750, 705 and 755. My suggestion is to always use 755 for directories and 644 for files. But be sure not to use 777 on anything!

      I hope that helps.

      • Shirley says

        Yes that’s helps a lot Regina…I no longer host with GoDaddy but you’ve given me a much better understanding …thanks again

  3. says

    I’ve done an install, and so far everything looks great! What I haven’t done is upgrade any existing sites, since I’m pretty sure there will be some problem, some where. Always is it seems.

    I’m going to be digging in a bit this weekend and maybe start creating a new theme with this version. Can’t wait to play with the taxonomy shtuff. ;)

    • says

      Wayne,

      Thanks for sharing. I tried the beta version on a test site and it look fantastic. I am going to delve in this weekend myself and check it out. I have customization done in several areas (not my core, of course) and have to see if all goes well.

      Cool, new theme! Be sure to let me see when you get er’ done.

      I am looking forward to the new taxonomy stuff too. You might want to check out this cool article by Cosmin Negoita, “The Essential Guide to WordPress 3.0 Custom Taxonomies” at http://www.1stwebdesigner.com/wordpress/essential-guide-wordpress-custom-taxonomies/.

  4. Petrus4 says

    Hi There,

    I upgraded my production site from 2.9 to 3.0 (yes I know, not the best idea without testing) and yes I got a white screen! Turned out one of the plugins was the issue. I temporarily renamed to plugins folder which allowed the site to work again. I then went in and enabled plugins one by one until I got the error again. It turned out to be WP Events Calendar plugin which has know issues with WP 3.0. See http://www.wp-eventscalendar.com/ and http://wordpress.org/support/topic/409138 Hopefully the issue will be fixed soon.

    • says

      Hi Petrus4,

      Thanks for letting us know there is an issue with the WP Events Calendar plugin. Luckily, I’m not using that one.

      I have seen that “white screen of death” too many times and have learned that 99.9% of the time it’s a plugin conflict. Glad to hear you knew to change the plugin directory name and enabled one by one to find the culprit.

    • says

      Thanks Justin. Yes, I’m thrilled about that part! You would not believe how many websites we work on that have the username “admin” and the password “password.” I am hoping that people will learn to use something other than “admin” out of the gate now.

  5. John Hoff says

    Hi Regina,

    I of course have been in head deep security-wise as far as WP 3.0 goes and the only main security enhancements I’ve seen thus far are 3 things:

    1. Automatic generation of security keys
    2. Ability to create your own customer username
    3. Ability to change your default database prefix

    Have you noticed any other security enhancements on the end-user side of things?

  6. says

    Thank you for this interesting write up, I have been pondering upgrade and this has motivated me to doing it sooner than later. Every bit of security helps the online real estate.

  7. Rob says

    I am planning a WP Blog based on WP 3.0 but have been told that I will have nightmares getting it to work properly with SSL certificates. Is there a good, idiot level article on configuring and asjusting WP 3.0 to work with SSL without generating errors or irritating visitors with constant pop-ups asking them if they want to upload insecure content as well as secure? I do NOT want to rely on plug-ins to get good SSL integration. I have tried this before with earlier WP versions and it is just to fussy and prone to issues. It would be great if WP could take all of these issues and build them into SSL integration controls on the Dashboard in future releases. Thanks.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

CommentLuv badge