Using Vagrant for WordPress

In the beginning, we had M/W/X/AMP(/P/S)

One common way to spin up a server for local WordPress development involves using an Acronym Soup server locally, AMPPS, MAMP, Bitnami MAMP Stack, WAMP, XAMPP, or a built-in development server (like the Apache that ships on Mac OS).

The upside to this is that you can quickly spin up a local server and start banging out some code for your project.

The downside to this is that your local development environment may not match your staging and/or production environment(s). You may have to maintain multiple versions of tools locally on your desktop or laptop that are unwieldy or cumbersome from one project to the next. You may need to share a configuration with your team mates that can’t be replicated without giving them a list of tools they need to install and the instructions to do so. You may be using Apache locally, and have Nginx on production. You may be using PHP 5.4 locally, and have PHP 5.3 on production. PHP libraries may be missing from your local dev server, or vice versa. Your installed version control system may have a different binary version locally than it does on production.

Then we had the VM

This is where a virtual machine (VM) can be very useful.

Traditionally, spinning up a VM involved downloading pre-configured boxes for Virtualbox or VMWare that were sort of like the target production environment. They might be overloaded with lots of preconfigured software that may not be necessary, or have a complete GUI attached to them, making the VM large and unwieldy. They might be missing some packages that you need that are specific to your production environment. Depending on how the box was created, you may end up with bloated boxes that are a pain to manage, and sharing the 10 GB VM amongst a team that includes remote workers may be unfeasible. Do you check the VM into version control for the project? How large do you want your version control repository to be on initial checkout for that newb on the project?

Then came Vagrant

This is where Vagrant comes in.

From Vagrant’s About page :

Vagrant is a tool for building complete development environments. With an easy-to-use workflow and focus on automation, Vagrant lowers development environment setup time, increases development/production parity, and makes the “works on my machine” excuse a relic of the past.

Using Vagrant, you can define and spin up a headless server environment that can be used for local development. Some cloud providers, such as Amazon Web Service and Rackspace, even support Vagrant boxes as production servers.

You could start with a base box definition that closely resembles your destination production environment by finding one at the Hashicorp Vagrant community box repository, or from the repository.

Technically you could configure a Vagrant box, spin it up, and begin installing all the necessary packages for your server at the command line with apt-get, yum, or whatever package manager the OS of the Vagrant box provides.

Managing installed packages

Fortunately, there are tools to automate and assist with package management as well.


Puppet is a tool designed to manage the configuration of Unix-like and Microsoft Windows systems declaratively. You can use Puppet to manage packages for you.

You can use Puppet to install Apache, or Nginx, MySQL, PHP and other packages that your Vagrant box needs to match production. With Puppet and Vagrant together, you can create virtual machines that reliably match your production environment to a tee.


PuPHPet is and online “wizard” that allows you to create a Puppet and Vagrant configuration without a deep knowledge of either tool’s specific configuration formats and directives. You could go to the PuPHPet website, spec out the OS, hostname, memory allocation, installed packages, etc., and download a zip archive that contains the configurations. Unzip the archive on your local machine, cd into it, run vagrant up, and your server is ready, without learning all the details of configuring Vagrant or Puppet directly.

Using a tool like PuPHPet, it is a breeze to define the Vagrant box, the OS and installed packages, the whole nine yards, and check the entire configuration into version control. While still being lightweight, your team can check out the configuration, run vagrant up, and start developing in a production environment quickly.

WordPress Vagrants

There are a number of WordPress specific Vagrant Projects that you could use to jumpstart your WordPress development, depending on your needs.

WordPress specific Vagrant boxes aren’t typically aimed at helping you match a specific server environment. They are usually intended to quickly spin up a type of WordPress project setup, i.e. for WP Core contributions, WP Theme Reviews, WP theme development, WP plugin development, or even client site development. They often come pre-loaded and configured with WordPress development tools, and some of them follow best practices for large scale WordPress production environments. They can be quite useful, for example, if you need to share a server configuration amongst a team, or if you need to do VIP development.

VIP Quickstart

VIP Quickstart is a local development environment created by Automattic for VIP developers. The goal is to provide developers with an environment that closely mirrors along with all the tools they recommend developers use.

Varying Vagrant Vagrants

The “big guy” in WP specific Vagrant boxes, this is the one you will hear of most often when researching Vagrant with WP.
Although it started as a 10up project, it has transitioned to a community project.


Chassis is a virtual server for your WordPress site, built using Vagrant.
From the project README: You can imagine it as MAMP/WAMP on steroids.

Primary Vagrant

Developed as a VVV alternative that uses Apache instead of Nginx.

Useful WordPress Vagrant Tools

VVV Site Wizard

An Alison Barrett project (Nerdery Alum, former Automattician, current 10up).
A Bash script to automate setting up new WordPress sites with Varying Vagrant Vagrants.

Variable VVV

A fork of VVV Site Wizard that adds a number of useful features, including deployment options.
Although I have not had a chance to test it, it looks like a very interesting project tool worth exploring.

WordPress Theme Review VVV

A VVV setup script intended as a WPTRT theme review environment.

Vagrant Manager

A handy tool (available for OS X and Windows) to manage your Vagrant boxes right from the desktop.
See which Vagrants are running or halted, and issue commands to them from an easy to use menu.

Hey, where’s the tutorial, code, or in-depth walk-through?

This post isn’t a tutorial. This post is a brief intro to what Vagrant is, and why you should consider using it for WordPress development.

I hope to inspire WordPress developers who may have “heard” of Vagrant, but aren’t sure how it can be useful for them, or don’t know where to start, to dig in a little deeper. Look into some of the GitHub repos I’ve linked to, and see if one of them might work for your next project. Try using PuPHPet to build your own ideal Vagrant setup for your next WordPress project.

My advice, if you haven’t used Vagrant before, and you just want to get started with using Vagrant, clone Alison Barrett’s VVV Site Wizard and follow the directions. You’ll have a WP specific Vagrant box up and running in no time.

If you want a little more fine grain control over your Vagrant box setup, go to the PuPHPet website and spec out your ideal box. Then the rest… setting up a DB, installing WP, etc., is in your complete control.

Hey, what about Chef / Berkshelf, or Ansible, or SaltStack, or (insert yet another tool name here)?

Yup. Those are other tools that you can use, rather than Puppet. I’ve heard great things about them, however, I have not had the time to dig into all of them myself.

If you have the time to research them, and you find a compelling reason to use one over another, by all means, use it, write about it, then share your discoveries and experiences. The single greatest thing about the WordPress community, I have found through the years, is all the knowledge that the community shares.

24 Hours of Madness (for a good cause) – The 2014 Overnight Website Challenge

Adam Richards and myself pressing all the words.
Adam Richards and myself pressing all the words.

24 hours of no sleep.

Well, it’s actually more like 30 hours or so.

No sleep.
Coding through the night.
In a mad dash to help a non-profit in need.

For the second year in a row, I participated in the Overnight Website Challenge in Minneapolis.

Last year’s Overnight Website Challenge was a disappointment for me. My 2013 team put all of our best effort and our hearts into it, but we ran into insurmountable problems that prevented us from completing the challenge in the 24 hour allotment. The few of us who had a passion to complete the project, did so months later, after a lot of additional work. I told myself “I’m not doing the OWC again,” I didn’t want to feel that disappointment all over again, and lose precious sleep to boot. But, some of my teammates from 2013 wanted to participate again, and I felt the need to support them, and do a good deed for a non-profit.

I had a damn fine team this year. Adam Richards , Brant Day, Bree Compton, Chris Bennett, Corey Stern, Jon Winton, Scott Garrison, Shane Smith, Sherman Bausch, and myself, flying under the banner of Team Raxacoricofallapatorius. We had UX, QA, front end, Javascript, and WordPress back end devs represented on the team. A well rounded, complimentary skill set, and we all worked well together. Tensions and frustration were minimal, technical glitches were few, everyone knew their role and played their part.

We gave our all for 24 hours straight. Coding through the night, until eyes were sore, blurry, bloodshot, filled with tears, with eyelids so heavy it hurt. Committing code up until the last minute, barely able to form complete sentences for git commit messages, but we carried on, doing whatever was needed. We created a fine product for a fine non-profit, and the product was “launchable” at the end of the challenge.

When the challenge was complete, I made the trek home, fell into the most comfy bed I have ever slept in, and slept for 12 hours straight. My family came home. I awoke long enough to hug each of the children, tell my wife I love her, and I fell asleep again, for another 6 hours or so.

Monday was a blur, much like the weekend, and all I could think of is more sleep.


And Batman.


Using Composer for WordPress Package Management

Composer is a PHP based “dependency manager”.

A “dependency” is any code or library that your site needs to work properly.
For instance, in a WordPress project, the WordPress core itself is a dependency.
Your WordPress site is dependent upon WordPress core. Without WordPress core, the site won’t do much of anything.
WordPress Plugins and themes that you need for your WP project are also be dependencies.

There are clear advantages to adding Composer to our developer toolbox.
We can use Composer to “spin up” our project, to download WordPress core and any necessary plugins, even run custom install scripts.
We can avoid committing publicly accessible plugin and theme packages into our project’s version control, keeping our repositories lighter.
We can avoid using Git submodules or SVN externals to include WP core, plugins and themes in our projects.
We can manage both WordPress and non-WordPress PHP packages for our project with the same set of tools.

Obviously, you do need Composer itself installed before you begin. Composer can easily be downloaded and run in minutes, have a look at Composer’s install instructions. I prefer the “global install” method so that I can just run the composer command directly, instead of php composer.phar.

Basic usage of Composer is fairly simple and straightforward. At its simplest, you write a “manifest” in JSON format, called composer.json. This manifest is where you will detail the specific dependencies for your project, including the versions of the dependencies.

If you wanted to write a composer.json file that simply required WordPress core for your project, it could look as simple as this :

    "name": "richaber/install",
    "description": "Install WordPress",
    "type": "project",
        "repositories": [
                "type": "package",
                "package": {
                    "name": "wordpress",
                    "version": "3.8.1",
                    "dist": {
                        "type": "zip",
                        "url": ""
    "require": {
        "wordpress": "3.8.1"

Save the above as a file called composer.json, and drop it into an empty web root for testing. In your command line, cd to that web root and run composer install.

You should see output similar to this :

Loading composer repositories with package information
Installing dependencies (including require-dev)
    - Installing wordpress (3.8.1)
    Downloading: 100%
Writing lock file
Generating autoload files

In the manifest, you defined a repository where the WordPress core package resides.
When you ran the install command, Composer reached out to the dist url, grabbed the zip archive, downloaded it to your directory, and unzipped it for you.

But where the heck is WordPress in this directory?
Well, by default, Composer installed it into a sub-directory called “vendor.”

└── vendor
    ├── composer
    └── wordpress   <-- HERE'S WORDPRESS CORE

Obviously, that isn’t entirely helpful for us. But fear not, we have solutions.

So we have 2 ways we can go from here…

Install WordPress core directly into the web root, so it looks like a “normal” out-of-the-box WP install, complete with loose files jangling all about the web root.
Install WordPress into its own directory, a subdirectory of the web root, sometimes called version-control friendly or VIP structure.

Since I work with teams that use SVN or Git for version control, and since I have done some WPCOM VIP work, I prefer the version-control friendly or VIP structure. You do use version control, don’t you? Of course you do, so let’s go that route.

We want to install WordPress in its own directory, named “wp.”
We could call it something else, like “core” or “wordpress,” but we’re going with “wp,” to mimic VIP style.
We could do a whole bunch of work ourselves to pull this off, everybody loves re-inventing the wheel.
Or we could lean on the existing work of others in the community.
The beauty of the open source WordPress and Composer ecosystems is, other people have probably run into the same issues we have, and someone has likely engineered a well-tested solution with advice and contributions from the community.

John P. Bloch is a well-known and respected developer at 10up, and he has been actively contributing tools for WordPress back to the community. John has a Composer package for installing WordPress into a specific directory which we can employ here, johnpbloch/wordpress-core-installer. Even better yet, John’s johnpbloch/wordpress Composer package is WordPress core with Composer support added. This can simplify our composer.json even further, by removing the block that defines the WordPress zip archive package, and as an added bonus, the johnpbloch/wordpress package includes the wordpress-core-installer package as a dependency itself.

Here is our simplified composer.json manifest, using John’s WP package, note that we have defined the wordpress-install-dir in the “extra” section:

    "name": "richaber/install",
    "description": "Install WordPress",
    "type": "project",
    "require": {
        "johnpbloch/wordpress": "3.8.1"
    "extra": {
        "wordpress-install-dir": {
            "johnpbloch/wordpress": "wp"

Now we save that composer.json and run composer install…

$ composer install
Loading composer repositories with package information
Installing dependencies (including require-dev)
    - Installing johnpbloch/wordpress-core-installer (0.2.0)
    Downloading: 100%
    - Installing johnpbloch/wordpress (3.8.1)
    Downloading: 100%
Writing lock file
Generating autoload files

Now let’s have a look at our installation again…

├── vendor
│   ├── composer
│   └── johnpbloch
└── wp              <-- HERE'S WORDPRESS CORE

Alright, now we’re getting closer to seeing some magic.
Let’s also install a plugin and a theme!

By default, Composer searches the main Packagist repository, which has all kinds of useful packages, but not necessarily the plugins and themes. Fortunately for us, there is a package repo that is specifically geared towards WordPress plugins and themes, WordPress Packagist from Outlandish LLP. Putting wpackagist to work for us is as simple as adding it to our list of repositories for Composer to search, requiring the necessary plugins and/or themes, and then defining the plugin and/or theme install paths.

WordPress Packagist uses plugin and theme slugs that match those at So if a plugin is found at the page then the plugin’s slug is wordpress-importer, and the wpackagist package would be wpackagist-plugin/wordpress-importer. If a theme is found at then it’s slug is twentyfourteen, and it’s wpackagist package would be wpackagist-theme/twentyfourteen.

WordPress Packagist uses composer/installers to target the custom install paths for themes and plugins. We will explicitly add composer/installers as a requirement to our manifest.

We will install our plugins and themes into a sub-directory of web root, which we will call “wp-content.” We could have called it “content” or “not-core-junk” or whatever, but I chose “wp-content” so we can mimic VIP style. Note that we do not install anything in the wp/wp-content directory, we don’t want to pollute that dir in this version control friendly structure.

Let’s start with 1 plugin and 1 theme. We add wpackagist to our list of repositories. We add composer/installers, wpackagist-plugin/wordpress-importer, and wpackagist-theme/twentyfourteen to our requirements. And we define our custom installer-paths for plugins and themes in the extra section.

    "name": "richaber/install",
    "description": "Install WordPress",
    "type": "project",
    "repositories": [
            "type": "composer",
            "url": ""
    "require": {
        "johnpbloch/wordpress": "3.8.1",
        "composer/installers": ">=1.0.12",
        "wpackagist-plugin/wordpress-importer": "*",
        "wpackagist-theme/twentyfourteen": "*"
    "extra": {
        "wordpress-install-dir": {
            "johnpbloch/wordpress": "wp"
        "installer-paths": {
            "wp-content/plugins/{$name}/": ["type:wordpress-plugin"],
            "wp-content/themes/{$name}/": ["type:wordpress-theme"]

Save it, and run it.

$ composer install
Loading composer repositories with package information
Installing dependencies (including require-dev)
    - Installing johnpbloch/wordpress-core-installer (0.2.0)
    Loading from cache
    - Installing composer/installers (v1.0.19)
    Downloading: 100%
    - Installing johnpbloch/wordpress (3.8.1)
    Loading from cache
    - Installing wpackagist-plugin/wordpress-importer (0.6.1)
    Downloading: 100%
    - Installing wpackagist-theme/twentyfourteen (1.3)
    Downloading: 100%
Writing lock file
Generating autoload files

Now let’s have a look at our installation again…

├── vendor
├── wp
└── wp-content
    ├── plugins
    │   └── wordpress-importer 
    └── themes
        └── twentyfourteen 

Well, this is starting to look a little more useful now, isn’t it?
We have WordPress core in a wp sub-directory of web root.
And we have plugins and themes in a wp-content sub-directory of web root.

Now, if you’ve never used the version control friendly structure before, there’s plenty of existing documentation about working with this structure. Essentially you just need to do a little work defining some constants in wp-config.php, and add an index file in the web root that kicks off WP.

We can create a standard wp-config.php file in our web root, and add a couple of constants into it that tell WordPress where to find content (wp-content) and core (wp) since they are not in the “famous 5 minute install” locations. In particular the values for WP_SITEURL, WP_CONTENT_DIR, WP_CONTENT_URL, and ABSPATH will not be “standard” and should be explicitly defined. Assuming that you’ve set up your basic wp-config.php in web root already, you can see an example of the constants to define below.

define('DB_NAME', 'database_name_here');
define('DB_USER', 'username_here');
define('DB_PASSWORD', 'password_here');
define('DB_HOST', 'localhost');
define('DB_CHARSET', 'utf8');
define('DB_COLLATE', '');
define('AUTH_KEY',         'put your unique phrase here');
define('SECURE_AUTH_KEY',  'put your unique phrase here');
define('LOGGED_IN_KEY',    'put your unique phrase here');
define('NONCE_KEY',        'put your unique phrase here');
define('AUTH_SALT',        'put your unique phrase here');
define('SECURE_AUTH_SALT', 'put your unique phrase here');
define('LOGGED_IN_SALT',   'put your unique phrase here');
define('NONCE_SALT',       'put your unique phrase here');
$table_prefix  = 'wp_';
define('WPLANG', '');
define('WP_DEBUG', true);

/** ↑ Typical wp-config stuff (comments removed for brevity) ↑ **/

define('CORE_STRING', 'wp');
define('CONTENT_STRING', 'wp-content');

/** @var string WP_HOME The site's URL, no trailing slash @link */
define('WP_HOME', '');

/** @var string WP_SITEURL WordPress core URL, no trailing slash @link */
define('WP_SITEURL', WP_HOME . '/' . CORE_STRING);

/** @var string CONTENT_DIR WordPress content directory, no trailing slash @link */
define('WP_CONTENT_DIR', dirname(__FILE__) . '/' . CONTENT_STRING);

/** @var string CONTENT_DIR WordPress content URL, no trailing slash @link */

/** @var string ABSPATH Absolute path to the WordPress core directory, with trailing slash */
if (!defined('ABSPATH')) {
    define('ABSPATH', dirname(__FILE__) . '/' . CORE_STRING . '/');

/** ↓ Last of the standard wp-config stuff ↓ **/

/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');

Now how about that index.php file that we need in our web root…

define( 'WP_USE_THEMES', true );
require( dirname( __FILE__ ) . '/wp/wp-blog-header.php' );

Now we have a basic WP installation ready. Add some DB magic and maybe an htaccess and you could start working with this right away.

Obviously, this can get more complex if we start running post-install-cmd and post-update-cmd scripts. We could load require-dev plugins that are specifically for development and not production, etc. But hopefully the baby-step-by-baby-step above gives you a better idea of how to begin using Composer for WordPress Package Management, without overwhelming you.

Why Most Stories About WordPress Security Are Wrong

This article originally appeared on the blog on September 11, 2013 under the title “Why Most Stories About WordPress Security Are Wrong.”

I have often heard the remark “WordPress is insecure!” My response is “Where did you hear that?” and “When did you hear that?”

WordPress Is the Most Popular Content Management System on the Planet.

My first question, “WHERE did you hear that?” is a very important question. As of this writing, “WordPress powers roughly 18% of the top 10 million websites on the planet, making it the most widely used CMS in the world. The next largest CMS is Joomla, with 3% of the top 10 million sites, and followed by Drupal at 2%.” [1] [2] [3] That’s a lot of websites running WordPress! This popularity and widespread usage means that WordPress has a much higher profile than other Content Management Systems (CMS). [4] [5]  A larger install base means a larger target for attackers looking for low-hanging fruit. The popularity of WordPress brings with it inaccurate or ill-informed attention from journalists and bloggers. Many of those who report on technology matters are not security experts, and often they lack a thorough understanding of the issue. A reporter saying “(WordPress is) pretty easy to hack” in reference to a scripted brute force attack against weak passwords, does not make it so.   The high profile nature of WordPress solicits the attention of security firms who may have an interest in attracting new customers to a product they offer. By issuing vague security white papers directly to the media, these firms might demonstrate that they are more interested in public relations and “free ink” than actually benefitting the WordPress community.   And just like the “Mac versus PC” debates, and the “Ford versus Chevy” debates, there is often a personal preference involved. A developer may prefer Drupal or SharePoint over WordPress, they may honestly believe that their preferred CMS has a better security model. But without being able to cite specifics, they may rely on the rallying cry “WordPress is insecure!” Just as a Macintosh enthusiast may (incorrectly) say “Windows gets viruses and Macs don’t.”

WordPress Is Secure, You Are Not.

WordPress core is, in fact, very secure, just as secure as any other Content Management System, just as secure as any other software suite or Operating System. Security issues most often arise from administrators and users. In other words, you are the weakest link. A weak password and/or a password used across multiple services, in conjunction with an easily guessable username, is typically the vector of attack against any website. A weak password means a brute force attack script can hammer away on your website until it hits just the right combination to get in, open a back door, add your site to a botnet, lock you out of your site, and potentially infect the computers of your site visitors. This is not a WordPress specific security issue, this is a user issue. If you administer a website, you are an IT professional, own a computer, or have used a computer in the last 20 years, then you should already be aware of the risks of weak passwords. The strategy for preventing exploitation of this attack vector is simple, do not use weak passwords, do not reuse passwords, and do not use easily guessable usernames (like “admin”). The next likely attack vector is an attack at the file system level of a shared web hosting server. A shared host could be running hundreds of websites on one server. An exploit might not come from an attack directly against your website, but your site can be incidentally compromised if an attack was successful against another site on the same server. The simple solution to this is to use a dedicated or virtual server, avoid shared hosting. For script kiddies, crackers, and botnet operators, the ever-growing pool of WordPress installs means that there are more sites to check for “low hanging fruit” vulnerabilities. Old versions of software can be compromised because of known vulnerabilities and exploits. The “bad guys” run automated scripts that check what version of a CMS you have, and if they find a version with a known vulnerability, they deploy an exploit and compromise your site. This is not a WordPress specific security issue, this happens with all major software. The solution is to keep your software and all associated add-ons up to date. With WordPress, all it takes is a simple click to keep your installation upgraded. While it is true that WordPress core is quite stable and secure, security issues can be introduced by third-party software. For instance, a few years ago, there was a widespread attack against websites that implemented the TimThumb image processing script. [6] Though the TimThumb script is not part of WordPress core, some third-party themes and plugins were using it as an image processor. As a result, an incredible number of websites (estimated in the millions) were compromised, which included non-WordPress sites that had TimThumb installed. [7] Again, this is not an issue with WordPress core security. This is an issue with third-party software, plugins and themes. The solution to avoid this attack vector is to use themes and plugins listed on Do not use themes and plugins from untrusted sources.

Historical Legacy and the Current State of WordPress Core Security.

My next question, “WHEN did you hear that?” is an equally important question in response to worry over . Around 2007–2008, WordPress garnered some unwanted (though admittedly deserved) attention as a number of security issues (in particular SQL injection and code execution vulnerabilities) in WordPress core were exposed. [8] Of course, these security holes were patched by WordPress developers upon discovery. Those vulnerabilities apply to legacy branches of WordPress and are not present in the most recent WordPress release, 3.6. However, the buzz surrounding those vulnerabilities gave some the feeling that WordPress core was, is, and will forever be insecure. That is an inaccurate and invalid assessment when it comes to security. Based on the same criteria, I would argue that your preferred Operating System, software suite, and CMS, was, is, and will forever be insecure. Security breaches and vulnerabilities have been discovered, exploited, and patched in all software. All software is terribly complex, be it an OS, a CMS, or your favorite Word Processor. Due to that complexity, all software suffers from some vulnerabilities (known and unknown) of some kind. All responsible software vendors and developers actively investigate and address vulnerabilities as part of their release cycle. WordPress, Joomla, Drupal, SharePoint, or any other major CMS is no different.

The Real Indication of How Secure a CMS Is, Is Determined by the Vendor’s and Developers’ Response to Security Issues.

For WordPress, the response was to implement an easy “click to update” functionality in WordPress’s Admin Dashboard, a regular release cycle to continually patch and improve core, and a full-time security team to continuously address security issues. Upgrading WordPress core is easy, it is so “WordPress.” When an administrator with proper privileges accesses the WordPress Dashboard, and an update to WordPress core is available, a simple “WordPress x.x is available! Please update now.” banner displays at the top of the screen. “Update now” is a link to initiate the upgrade process. Additionally, an “Update to x.x” button displays in the “Right Now” metabox. Clicking the “Update” button also initiates the upgrade process. The upgrade process itself consists of clicking a button, waiting a couple of minutes, and you’re done. This makes it easy for a site administrator to keep their installation patched for the latest security fixes. This simplicity is akin to the simplified update systems that the major OS vendors have implemented. Making updates simple means that users are more likely to keep their software patched. And of course keeping software secure means continuously applying security patches. A regular, ongoing release cycle addresses WordPress core security issues as they are discovered or reported. The release cycle consists of major version upgrades to add features to WordPress, and minor release versions as needed to address security vulnerabilities and critical bugs. [9] If a critical security vulnerability is identified in core, a security release that addresses the vulnerability is released as quickly as possible (usually within days, sometimes even faster). The number of critical or severe vulnerabilities discovered in WordPress core has decreased significantly since the 2007–2008 years, in part due to the regular release cycle, the simplicity of upgrading, and of course, the security team. WordPress has a dedicated security team that actively investigates and patches core to address security concerns. This team keeps abreast of all security issues, and enforces security procedures within core. The WordPress security team has a standardized process to address security reports: [10]

  1. Receive and acknowledge security report
  2. Work to confirm the report and its severity
  3. Plan and develop initial patch to address the security report
  4. All of this typically happens within 48–72 hours of receiving a security report.

“The WordPress security team is made up of 25 experts including lead developers and security researchers — about half are employees of Automattic, and a number work in the web security field. We consult with well-known and trusted security researchers and hosting companies.” — Andrew Nacin, WordPress Lead Developer, in a presentation “ & Optimizing Security for your WordPress sites,” June 2013. [11]

In conclusion, the vast majority of fear surrounding “WordPress insecurity” is unfounded, and most often is completely unrelated to WordPress core itself. WordPress is secure. What you do with it, how you deploy it, how you administer it, that’s where the real security concerns lay. Here are some helpful guidelines to keeping your WordPress website safe (for more in-depth security hardening guidelines, visit the Hardening WordPress page in the Codex)

  • Use a dedicated or virtual server, avoid shared hosting
  • Back up your site (files and database) regularly (consider a service such as VaultPress)
  • Keep your WordPress core installation up to date
  • Keep your WordPress plugins up to date
  • Keep your WordPress themes up to date
  • Uninstall (not just disable) any unused plugins or themes
  • Avoid plugins and themes from untrusted sources
  • Do not use admin (or other easily guessable usernames)
  • Use a strong password!
  • Ensure your own PC is malware free (to keep keyloggers and malware from stealing your credentials)
  • Monitor your server and user stats
  • Restrict WP-Admin to your VPN or proxy
  • Restrict WP-Admin using HTTP Basic Auth
  • Restrict WP-Admin to your IP address
  • Deny access to wp-content directories
  • Remove WordPress version from meta
  • Protect WP-Admin with authentication
  • Force SSL
  • Get a security audit
  • Report potential core vulnerabilities
  • Report potential plugin vulnerabilities

If you’re interested in notable WordPress users, there is an ever growing list of government entities, educational institutions, major brands, celebrities, and musicians that rely on WordPress as a secure Content Management System to power their websites and blogs. Visit the WordPress Showcase to see some of the big names that trust WordPress security.

So many websites, so few passwords

This article was re-published, with permission, in Chicz magazine Autumn 2012 issue, under the title “Passwords can be both strong and simple.”

I was recently asked to install an operating system and software for a friend. He gave me the password he wanted to use for his computer login, and also asked me to set up access to some of the websites he uses regularly. Unfortunately, I discovered that he is one of those people who uses the same username/email/password combination for multiple accounts and websites. If I thought this individual would listen, I’d sit him down for an hour and give him an introductory lecture on online security.

Folks in the security community will tell you that you should not use the same credentials for multiple websites and computers. But so many of my friends and family don’t seem to exercise this amount of caution.

For those of us who deal with web development, IT related work, and security, this seems obvious. The reason being, if a malicious individual manages to acquire your credentials, either by cracking your password, or by stealing it, or through your own carelessness (logging in from a public computer for example), they can effectively control your entire online presence. If you use the same username/email and password for your bank account, your Facebook account, your Twitter account, your Google account, your iTunes account, you have given the “bad guys” the keys to your kingdom. They can empty your financial accounts, make bogus purchases on your dime, scam your friends and family, and lock you out of your digital life by changing the password before you have even noticed that something is wrong.

And these days, there are a lot of threats to your credentials online. There are numerous cracking groups dumping the data from their exploits. If you had an account on the Playstation network, for instance, your credentials (and possibly financial details) may have been exposed in the much publicized attack that took place earlier this year (April 2011). The people who perpetrate these types of attacks often sell the data they obtain to less than reputable folks who use the information for ill, or they dump it on websites for other crackers to sift through for fun and for profit. If your credentials (email, username, password) were in one of those dumps, and you used those same credentials on multiple services (think Gmail, Hotmail, iTunes, Facebook, Twitter, your bank), then you could be in serious trouble. You didn’t just lose information for one website or online service, you’ve lost control of all of them.

The most common reasoning that I have heard for using one password for multiple sites/services/accounts is “I can’t remember multiple passwords.” While that may seem like a legitimate argument to a non-technical user, there are a myriad of tools available that can aid in managing multiple passwords. With these tools available, and many of them completely free, there is no excuse for using the same credentials for multiple systems, services, and websites.

KeePass, LastPass, 1Password, and Keychain Access are examples of tools that can be used for password management. These tools allow you to store multiple passwords in a secure, encrypted form, that can be retrieved as needed through a master password. So, for instance, you can have any number of username/password combinations for your online website accounts, safely stored in a manner that is unreadable. When you need to access the password for a particular account, you enter a single master password that you can remember, to retrieve one of your encrypted passwords.

The password manager that I am most familiar with is Keychain Access, built into the Macintosh Operating System since OS 8. Because it is a Mac specific application, integrated directly into the Operating System, many Macintosh applications and the OS itself can access the Keychain for storage and retrieval of credentials. So, for instance, if I were to set up an account on a website, using Safari, Safari can store the login credentials in the Keychain for use at a later date. When I access that website again in the future, Safari will ask for my permission to retrieve my website credentials from the Keychain. As long as I remember my master password (typically the same password used for login on the Mac), I will be able to access those stored credentials in the Keychain. One very strong master password allowing access to multiple unique passwords for website logins. Problem solved.

Of course, not everybody uses a Mac, so you may want to look into some of the alternative options.

I have some limited experience with KeePass, as I am a supporter of Open Source and was interested in how it functions. I found it to be a little cumbersome compared to the built in Keychain on Mac. But for Windows I have heard that the functionality is quite good, when used in conjunction with their browser plugins.

I have heard extremely good things about LastPass on Steve Gibson’s Security Now podcast. It really is worth checking out, and though I haven’t personally made the jump yet, LastPass will likely be my password manager for the future. It allows synchronizing across multiple computers, multiple web browsers (Explorer, Firefox, Chrome, Opera, Safari), and it is cross platform (runs on Windows, Mac, Linux, Android, iOS, WebOS, Blackberry). There is a free version, and a paid premium version ($1 per month billed annually), so there’s no reason not to at least give it a test drive.

Of course, if you’re going to use a password manager, you will need to be sure that your “master password” is of sufficient strength that it can resist attack. If someone were to crack your master password, then they would be able to access all of your services, just as if you had used the same password across multiple services. So your master password should be very strong, and there are a few guidelines you can follow to ensure that your master password is of sufficient strength.

Never use a single word, name, or common phrase. Passwords of that type are easily cracked by dictionary attacks. Use a combination of uppercase letters, lowercase letters, numbers, and symbols. Using a larger character space makes your password harder to crack, because it increases the number of variations a cracker would have to test against. Make your master password long. The length of a password increases the strength of it. It takes longer to crack a 24 character password, than it does to crack a 12 character password, again, because it increases the number of variations a cracker would have to test against. You can make a strong password by using a “padding” technique. Also called a haystack technique, essentially, you hide your needle (password) in a haystack (padding). By adding extra characters to the beginning and end of your password, you increase the length, thereby increasing the strength.

What follows is an oversimplified example. Do not actually use this example, it is merely for illustrative purposes. Let’s say you had a password phrase of “I love hats and cats”. You could begin constructing your password by doing a simple character replacement technique (substituting a symbol or numeric character for a letter) similar to “leet speak” and end up with “!10v3#@t5&C@t$”. That’s great, it includes upper and lowercase letters, numbers, and symbols. Although it isn’t likely that someone could guess that, it could be even stronger. If “!10v3#@t5&C@t$” is the needle, let’s throw it in a haystack and make it harder to find. We could pad the password with another 12 characters, 6 on each side (or 8 and 4, or 3 and 9, whatever to obscure it), and the padding could be just about anything. It could be random characters, or it could be a numeric sequence, or it could be an incrementing/decrementing number. Whatever is easy for you to remember, but isn’t completely trivial either. How about “ABCDEF!10v3#@t5&C@t$654321”? That’s an incredibly long and strong password, but it would be fairly easy to remember… if you love hats and cats that is.

Now, a real security guru would tell you that the character replacement technique I just employed (leet speak-esque) is a horrible idea, and if I was protecting national security I would agree. But, cracking that password would almost certainly require the attacker to know that you love hats and cats, and they would need to know that you have employed a specific padding technique. And if you have a 26 character password, containing 7 uppercase, 3 lowercase, 10 digits, and 6 symbols, it is highly unlikely that anyone would be able to crack that in your lifetime. Now I wouldn’t employ that technique on a critical system like a nuclear reactor, but for my own accounts, that is a very strong password that I am completely comfortable with.

Want more information about password strength? Read more about the haystack technique at GRC. You can also test the strength of your passwords with Microsoft’s online password checker. You may be shocked at just how weak your current passwords really are, and how you can increase their strength using some of the simple techniques I have described above.

To summarize, it isn’t really all that difficult to protect your credentials by increasing your password strength. And using a password management system to maintain unique credentials for the myriad of online services that we have all become dependent on in today’s digital life can protect your online identity from malicious individuals on the net. Don’t let yourself become a victim by using one password across multiple websites and services.

Update: 10/08/2012 — I have had many friends tell me over the years that they don’t care if someone hacks into their Gmail, or takes over their Twitter or Facebook account. What most of them have not considered, is how so many of these online cloud services are tied together. For an example of just how horrific the fallout of an online security lapse can be, read this article by Wired’s Mat Honan. He gives a first hand account of how he was recently hacked, his Google account was deleted, his iPhone, iPad, and MacBook were all remotely erased, including irreplaceable family photos, and his Twitter account became a platform for the hackers to broadcast racist and homophobic messages. Although Mat’s experience wasn’t directly related to the strength of his password choices, it is a clear indication of the potential damage that online security lapses can cause. Something to keep in mind the next time you consider tying multiple cloud services together, or using a weak password, or using the same password for multiple services.

Back To Security Basics

This article was re-published, with permission, in Chicz magazine Winter 2013 issue, under the title “SECURITY Basics.”

Malware, viruses, trojans, keyloggers, phishing… the internet can be a dangerous place to “live” and do business.

I recently had the displeasure of helping more than a couple of not-so-tech-savvy friends disinfect their home systems of various nasty infections. While working away on their computers, I asked probing questions to decide what sort of behavior opened their systems up to the “bad guys” in the first place. I found that in each case, a few things could have been done to prevent their computers from being infected. In one case, my own young son may have been the vector of attack, which lead to a discussion about basic online security not being taught in school… which in turn lead to this blog. My goal is to make my less than savvy friends, and my children, more aware of potential threats, how to recognize them, and how to defend against them. I hope to make my explanations as simple to understand as possible, I will attempt to keep the techno-babble at a minimum, though it can be difficult to gauge the understanding level of others, so if I speak “over your head,” it is not intentional, and your feedback could help me improve that.

Let me begin with the most simple, basic truism of computing…

Security 101: Everybody Needs Antivirus

Now this seems like a no-brainer to me. But I do continuously run into systems that are unprotected. Usually, though not always, these are Macs. To illustrate why Mac users need protection too, I am going to give a little Mac history, and hopefully the Windows users will be able to see how this applies to them without going into specifics of Windows malware history.

I am a Mac user and a Mac admin. I have personally seen Mac specific rootkits and viruses in the wild. I have witnessed system intrusions as they happened, and have seen files altered or deleted from disk while I watched. Don’t believe the hype that some magical Macintosh shield is going to protect you from viruses, trojans, malware, and the like. All operating systems are vulnerable to attacks, none of them are 100% safe. Don’t believe me? Google MAC Defender, but be careful what you click on.

Macs used to have such a small share of the personal computer market that they were virtually ignored by cyber criminals. Windows was the dominant system, and security on early versions of Windows was so lax that criminals were able to quickly write and deploy malware to Windows systems. Because of that, most Mac users felt invulnerable, they thought that Macs never got viruses. In reality, criminals just didn’t target Macs back in the “good ol’ days” because there were so few of them. Fast forward to 2011, Microsoft has (believe it or not) gotten very good at security (relatively speaking), making it more difficult for criminals to penetrate a fully protected and patched Windows system. Couple that with Apple’s amazing product successes over the last couple of years, and increasing market share. Now cyber criminals see walled fortresses when they look at Windows systems, and they see an increasing number of largely unprotected stick forts flying Apple flags popping up in back yards. That means there’s a potentially lucrative emerging market for malware in those shiny Apple boxes.

With that being said, we all need antivirus, Mac and Windows alike, but only install an antivirus solution that is 100% legit, that is from a reputable, well-known source. Avoid obscure antivirus products, products from companies that many people have never heard of, and never download antivirus from a file sharing site or peer-to-peer network. Installing a “cracked” or “pirated” antivirus product would be like handing the keys of your house to a burglar.

Know the name of your antivirus product, know the company it came from. If you see an antivirus window or message pop up on a website, tread very carefully. Criminals are known to frequently trick internet users into inadvertently downloading malware disguised as antivirus software. This is why you should be very familiar with your own antivirus product, so that you can differentiate what is a legitimate message from your antivirus, and what is a bogus message from “the bad guys” trying to trick you.

My antivirus recommendations.

Windows users should consider using Microsoft Security Essentials. This tool is not shareware, it is not crippleware, it is fully functional, no nag screens, no annoying messages, no tricks. It is a good antivirus product, provided for free, direct from Microsoft. This should be the starting point for providing basic protection on your Windows system.

Mac users should consider using Sophos Anti-Virus for Mac Home Edition. It is not shareware, it is not crippleware, it is fully functional, and does not have nag screens, annoying messages about upgrading, and constant attempts to trick you into paying for a bloated product. I use and recommend this tool from Sophos, it is a free, trusted, reputable, and fast antivirus package for Mac. It also helps me protect my Windows using friends by identifying and removing Windows malware from email, so I don’t inadvertently pass along infections.

Sure, there are more powerful antivirus packages that you can buy out there, but if you just want basic protection on your home computers, the products listed above are a good place to start.

If you really want to pay for an antivirus protection, then I would suggest McAfee Total Protection for Windows, or Intego VirusBarrier X6 for the Mac.