Top 5 WordPress Security Tips You Most Likely Don’t Follow

I recently gave a presentation at WordCamp Montreal on WordPress Security. While doing research for my presentation I came across a bunch of great WordPress Security tips that all WordPress users should use. Surprisingly, a good majority of these tips are not usually followed. Below is a list of the top 5 tips that most WordPress administrators do not do, but should:

1. Don’t use the admin account – The default user account that is created with every installation of WordPress is the admin account. Unfortunately the entire world knows this, including hackers, and can easily launch a dictionary attack on your website to try and guess your password. If a hacker already knows your username that’s half the battle. It’s highly recommended to delete or change the admin account username.

2. Move your wp-config.php file – Did you know since WordPress 2.6 you can move your wp-config.php file outside of your root WordPress directory? Most users don’t know this and the ones that do don’t do it. To do this simply move your wp-config.php file up one directory from your WordPress root. WordPress will automatically look for your config file there if it can’t find it in your root directory.

3. Change the WordPress table prefix – The WordPress table prefix is wp_ by default. You can change this prior to installing WordPress by changing the $table_prefix value in your wp-config.php file. If a hacker is able to exploit your website using SQL Injection, this will make it harder for them to guess your table names and quite possibly keep them from doing SQL Injection at all. If you want to change the table prefix after you have installed WordPress you can use the WP Security Scan plugin to do so. Make sure you take a good backup before doing this though.

4. Use Secret Keys – This is probably the most followed security tip on the list, but still I’m amazed at how many people don’t do this. A secret key is a hashing salt that is used against your password to make it even stronger. Secret keys are set in your wp-config.php file. Simply visit https://api.wordpress.org/secret-key/1.1 to have a set of randomly generated secret keys created for you. Copy the 4 secret keys to your wp-config.php file and save. You can add/change these keys at any time, the only thing that will happen is all current WordPress cookies will be invalidated and your users will have to log in again.

5. htaccess lockdown – This is actually my favorite tip from my presentation. Using a .htaccess file you can lockdown your wp-admin directory by IP address. This means only IP addresses you specify can access your admin dashboard URLs. This makes it impossible for anyone else to try and hack your WordPress backend. To do this simply create a file called .htaccess and add the following code to your file, replacing xxx.xxx.xxx.xxx with your IP address:
AuthUserFile /dev/null
AuthGroupFile /dev/null
AuthName "Access Control"
AuthType Basic
order deny,allow
deny from all
#IP address to Whitelist
allow from xxx.xxx.xxx.xxx

You can add multiple “allow from” lines so make sure to add any IP addresses you plan on accessing your site from (ie Home, Office, etc). Remember most ISP use dynamic IPs so your IP address might change on occasion. If you get locked out just update your .htaccess file or delete it all together. This obviously is not a good tip if you allow open registrations as you need to allow your users access to wp-admin.

I follow some of those tips. and some others as well.
The SQL threat is really stupid really. In my own projects I don’t use plain SQL anywhere. Don’t understand why it’s so popular with PHP applications. Bad design really.

#1 and #3 are simply security via obscurity, which is no security at all. #1 can easily be worked around if you remove or change the default username. A much better idea is to only use the admin account for actual administrating, and use a different account for everything else. Grant it the permission to do everything but change settings (Editor, I think).

#2 is somewhat valid however, because if for some reason PHP was temporarily disabled, wp-config.php could be read if in your web-accessible directory. Otherwise, it’s also security through obscurity.

#2 “move you wp-config file” is causing problems to some themes and plugins that load this file directly (and usually don’t check the alt. dir.). So I recommend to get your site into working state and after that implement the security tips carefully.

@Phil – if it’s up above the web root, then nobody should be able to get to it. If they can, then the box itself is compromised, not your install.

William forgot one more n00b tip: don;t use the same password for everything. I’ve seen an install that had the same password for ftp, the admin account AND the database user. Might as well hand someone the keys.

I follow most of them- much of which I learned last fall when my 14 blogs were all hacked. I also learned that hackers use bots to find blogs with certain vulnerable files and can also get the admin login easily – not from using a dictionary attack, but by posting AS the Admin. there is software and a whole procedure that hackers can use just by making posts as the Admin ( learned a good deal of this on YouTube and doing a Google search)

Something else folks should do, but get a bit lazy at is keeping WP and plugins updated. Know who developed the plugins you are using- some hackers have been known to create plugins just for the purpose of accessing your blog.
I agree use the wp security scan plugin as well as Login Lockdown, and Ask Apache- Password Protect ( which I have never been able to get all areas of that one working)

I tried to implement #2 by moving my wp-config.php file to the wp-admin directory. But then my site stopped functioning saying it needed a wp-config.php to work. I don’t get it, thought WP was supposed to look for it if it wasn’t in the root?

@Ryan McCue – Using an “Editor” account for posting and such isn’t always feasible. Many people post code snippets in their posts, and the last time I checked, this permission was not granted to anyone other than an administrator.

I have taken wp security very lightly until now. I was sure no hacker will notice my blog since it is small and doesn’t have high PR. Turns out hackers are not really picky at the sites they attack. I just noticed today my site having a different main page. Thankfully I was able to regain my wp dashboard after a few minutes of frantic research on what to do.

Simple steps that eliminate groups of common attacks are real security steps that should be taken, “Security Through obscurity” or not. OK they don’t address the security holes that let the people who really know what they are doing in, but let’s face it: most bloggers are not going to do a code review to see if a plugin adds slashes to data retrieved from the users or even an rss feed. So, these steps help most simple sites block most simple attacks. That’s a good thing.

#1, for example, eliminates dictionary attacks, cookie hash attacks and attacks that rely on the Admin user name or User ID. That’s a big group. My version of the tip is to login with the admin user long enough to setup a few users one of which is a user with admin access and then demote Admin/User #1 to a subscriber.
#2 I may add to my tool box. I don’t use it now.
#3 eliminates all pre-baked SQL injections. Yeah it’s just obscuring the name of the tables, but you know what, 99.9% of the attacks I’ve seen in the wild would be defeated by this. People copy a link and know just about enough to change the address of the blog inside that link. Beyond that their eyes glaze. So most simple worms that spread by looking for a weak plugin and inject code into wp_options will be blocked by this.
#4 is a must. Without this, if your hash is sniffed off of unsecure wifi or even someone just copying your cookie files, you’re up the creek. #nopaddles
#5 is not practical for many people and beyond what many can do. Personally, I would replace this one with a much more important one: Only use the most popular plugins out there. Most security breaches now come via plugins that open up holes. Mark Jaquith points out the simple fact that: The most popular plugins have had the most eyes looking at the source code. If you stick to the top 1/3 most popular plugins, you will be in pretty good shape. Less popular plugins will have been reviewed less often and are more likely simply be easy ways for people to add data to your database and files to your site.

All in all this stuff makes your site block some of the more common attacks out there. And again, that’s a good thing.

Thanks for these tips. I am certainly going to do the htaccess one, as I only ever access from home. If I do travel then it can be modified by ftp anyway? I always delete the admin account and do the secret keys to.

I always suggest that people also remove all visual signs that it is a WP blog. Remove the “powered by” link in the footer and do not put the META widget on – how hard is it to type wp-admin in the address bar? Little things keep people from finding you.

I see you have the “powered by” below. If you still want to give something back, then just change the words “Uses open source software” or something. Or just give back in other ways, by promoting it in your blog, telling friends etc.

Regarding moving the wp-config, is it possible to store it alongside other wp-configs, ie. rename them? I run a site that for historic reasons is 5 WP blogs each in a sub-directory. So I cannot just shift the wp-config up one level. Could I either rename the file, or specify a location?

@RD – OK So you’ve accepted my comments but not my URL? Why? Everyone else’s URL is accepted… So I contribute to your blog and readers but you won’t contribute something back to me? You should be ashamed of yourself!

P.S. I’ve removed my link from this comment – just to make you happy about yourself! :)

@Andrea_R – Even if on a perfect box, I can just do a include in a php file and echo the constants. I think, its just that it doesn’t spit out the contents if php is not working for some reason. Correct me if I am wrong.

I followed your advice on #5 ,htaccess lockdown and it took my entire site down! What ended up happening is that it blocked EVERY visitor except myself. I don’t believe I did anything wrong as I followed your instruction, but BE CAREFUL of this one. I lost an entire day of traffic and earnings because of it and didn’t even know until the end of the day when I checked my stats.

@Paul – sounds like the file is in your root directory. Move it over to the wp-admin folder and it will lock down that specific directory. The site will then be available publicly, but the wordpress backend and login will only be available to you.

As a complete newcomer to WP, I sure would have appreciated that this information be available when I installed WP. I’m going through Hell right now trying to change my ‘wp_’ prefix. The WP Security Scan is unable to change it automatically (even though I have ALTER privileges), so I’m having to manually edit the SQL backup. I can’t figure out how my ISP will let me re-import the data base: there’s an Export, no Import. Lotsa fun.

WP should prominently display this info during the installation process.

are only needed if you restrict access to the particular subdirectory by password protection. Since there is no user, group or path to a .htpasswd file the whole .htacess file fails. As soon as you allow ‘allow from all’ it no longer attempts to authenticate the access to the directory thus allowing the directory to show correctly. ”

Hey thanks for these tips, they are really great. I normally change the keys but I looked at some of my old installs, and the keys were missing. This is because they were added in WP 2.6 and although I upgrade diligently, I don’t ever update the wp-config.php file, so I’d say if you have any builds that were originally pre-2.6, then you should go in and make sure you’ve added the keys.

Also the .htaccess trick is simple and genius, probably the easiest thing on this list to implement, so I don’t get why people are having trouble with that one.

And finally to quote Kurt Cobain, “Just because you’re paranoid don’t mean they’re not after you”.

@Jon – when I was at word camp someone asked that and the answer right now is no AFAIK

I also like to use htpasswd to 2x password protect my admin panel.

Also, while I 100% agree you shouldn’t use the admin account it sucks that any use of author archives or author feeds use the username and not some different slug. So if you do use a different name and delete admin it is not hard to apply a dictionary attack from scraping the username from an rss feed.

@John Adams – A salt is similar to a nonce. It is a type of encryption that uses the secret key to generate a random mashup of the salt + password and sends it encrypted. This makes it harder for anyone to guess passwords or use dictionary attacks against them. The generated password has an expiry time which also helps deter attacks.

I’d add another security tip to this excellent list – change passwords regularly and make sure they are strong ones. There’s no such thing as 100% secure passwords and the longer an admin password sticks around, the more opportunities hackers have to decrypt them. Using a tool such as KeePass (http://keepass.info/ makes changing passwords a piece of cake. Use something like that to generate a very strong password (say, around 20 or so characters) enhances the security of the salted password. If the salt is, say 64 characters, and your password is, say 22 characters, that makes for an 86 character password that hackers would have to decrypt, unscrabble and try. It can be done, but it takes time and a hacker would have to be really determined to get in if they were going to be bothered trying.