Category Archives: Wordpress

WordPress Security Tip: NEVER Use Your Admin ID Visibly

WordPress is the most-hacked platform out there, and the most common attempt at hacking it involves attempting to get access to your administrative ID. For this reason you should

  • NEVER use an ID like “admin”, “administrator”, or the name of your domain for your admin ID — Pick an admin ID that will not be guessed!
  • NEVER use your admin ID to make postings or comments on your WordPress blog
  • NEVER publish a posting unless you’ve checked a preview to be sure you’re not exposing anything you don’t want to. Save drafts, use preview.

Here are some simple better practices to keep your admin ID safe:

  • Only use your admin ID for administrative tasks that actually require it.

    This includes things like updating themes and plugins — which you should be doing via SFTP — and so forth.

  • Create a second “public” persona and give it “author” or “editor” privileges only. Be sure to use this ID for anything that will be visible on your site.

    On this site, “Zanzibar McFate” has no administrative privileges. (He has a 30-character, randomly-generated password, in spite of that.)

Tip 1: Use the “Author” Pop-up Menu on the “Edit Post” page

If you click on the “Screen Options” button toward the top-righthand corner of the “Edit Post” page, it will drop down and present you with a number of things you can show or hide. Check the box next to “Author”.


Now, there will be a pop-up menu section below the editing panel on the edit post page which will let you select your “public persona” as the post’s author instead of your admin ID.


Tip 2: Use the WP Masquerade Plugin

Comments are a bit tougher to manage, since they’re published immediately. You can log out of your administrative ID and log in as your persona, but fortunately, there’s an easier way.

A nice tool to facilitate better operational security here is the WP Masquerade plugin. I can verify that it works with my WP 4.2.2 install. Download the plugin and activate it. Now, when you go to your user list as an administrator, there will be a hover-visible link beneath every user saying “Masquerade”, as shown.


Click on that link, and you’ll be effectively logged in as that user, and any comments you make will be posted under that ID. To close the Masquerade session, click on the link in the banner at the bottom of the page.


Alternatively, you can use the “Masquerade as…” drop-down which the plugin adds to the Admin toolbar.



Your WordPress administrative ID is — assuming you’ve installed and secured your WordPress correctly — the weakest link in your security chain. If you expose it publicly, you’ve greatly increased the susceptibility of your site to being hacked. Practice good opsec, and use the tools available to keep your admin ID under wraps.

The Most Recent Batch of Inept Hackers

WordPress is very popular. Very easy to install. Very easy to install incorrectly if you’re not entirely clear on how things operate on your hosting, and in my experience, even a lot of ISPs seem to not be entirely clear on that.

This is just a screenful’s worth of the security scan — I’m using the free WordFence plugin on that site, which is one of the better free ones out there — from one of the WordPress sites I run. Pretty typical.

If you’re not running some sort of live traffic and file system scanner on your WordPress site, you’re probably asking for trouble. If your administrative account has a name like “admin”, “Administrator”, or “«PASTE SOME PORTION OF YOUR SITE’S DOMAIN NAME HERE»”, or if you expose your admin account name in other ways (like via an “?author=” page, or by using your admin account as an author), you’re walking down dark alleys with twenty-dollar bills hanging out of your pockets.

If you’re using an account name like that and an easily-guessed (or duplicated) password, you’re probably already in trouble.

I’m going to have more to say on this when I get it all organized…

Set Up Your WordPress Site to Use Password-Free SFTP For Better Security

This turns out to be a pretty easy trick to do. In order to accomplish this, you will need:

  1. to be able to ssh (or, heaven forbid, telnet) into a command line on your server and operate as root or a “sudoer”;
  2. to be able to edit the wp-config.php file for your WordPress installation;
  3. to be able to stop and restart your web server.

Assumptions: You’re running CentOS or something like it. If you’re running Debian, or something like it, you’ll need to use apt-get instead of yum, and your directory layout will be different.

Enabling SSH for PHP

We’re going to set up WordPress to enable uploads via SFTP; for that, we’ll first need to build and install the ssh2 extension to PHP. At your server’s command line, execute the following to load all of the infrastructure you’ll need:

$ yum install php-devel php-pear gcc gcc-c++ make automake autoconf pcre-devel re2c libssh2 libssh2-devel

Next, have pecl install the ssh2 extension.

$ pecl install ssh2-0.12

Turn on ssh2 by creating an ini file for PHP:

$ echo "extension =" > /etc/php.d/ssh2.ini

Restart your web server:

$ service httpd restart

At this point, the SSH2 PHP extension should be installed and activated; you can use

$ php -i | grep ssh2

to verify this.

Setting Up WordPress for SFTP

First thing to do is to generate a key pair. YOU MUST BE LOGGED IN AS THE USER WHO WOULD BE DOING THE UPLOADING TO WORDPRESS. At the command line, execute

$ keygen-ssh

When prompted to enter a file name, we’ll call the key pair “~/wp_rsa”, so as not to accidentally overwrite any other keys we have around. Once your key pair has been generated, execute the following commands in that user’s home directory:

$ cat >> .ssh/authorized_keys
$ mv wp_rsa* .ssh/

For reasons that aren’t immediately clear to me, WordPress required both the public and private key to be available to it. Set the access protections appropriately:

$ chmod 755 .ssh/
$ chmod 644 .ssh/*

Next, edit wp-config.php, and add the following lines to the end, making the appropriate substitutions for your own site «where indicated»:

define('FTP_HOST', 'localhost');
define('FTP_USER', '«your user name goes here»');
define('FTP_PUBKEY', '«full path to user's home directory»/.ssh/');
define('FTP_PRIKEY', '«full path to user's home directory»/.ssh/wp_rsa');

Finally, set the protections and ownership on the wp-content directory to allow Apache to create things in there (assumption — I have ownership of my wp-content directory set to «site owner»:apache; you may need to adjust this to suit your specific situation:

$ chmod 775 «full path to WordPress directory»/wp-content

You should be good to go.

[This posting is an adapted excerpt from the upcoming book “McFate’s Indispensible and Comprehensive Guide to Building Bullet-Proof Servers”]