Codex tools: Log in
WordPress security matters a great deal to people who are deal with sensitive information and controversial topics, but should be one of the forefront issues for all bloggers and site administrators whether they are using WordPress or some other blogging tool.
WordPress developers take security very seriously. As with any other system, there are potential security issues that may arise. We will go through some common forms of vulnerabilities and how to deal with them.
Fundamentally, security is not about perfectly uncrackable systems. Such a thing might well be impossible to find and/or maintain. A secure server protects the privacy, integrity, and availability of the resources under the control of the server's administrator. As such, you should find a host you can trust to provide you with the software tools and support to adequately meet your needs.
Qualities of a trusted host might include:
Decide what security you need to apply to your server by determining what your server needs to run and what software and data needs to be secured.
Keep in mind some general ideas while considering security for each aspect of your server:
This list is not complete because no list can be complete for the security needs of every computer. These items simply provide some general advice for keeping common aspects of your WordPress hosting secure.
The computer you use to add new posts to WordPress is just as susceptable to malicious attack as any other computer on the internet. Software that compromises the security of your desktop system can become a gateway to malicious users to access your server.
Make sure the computers you use to post to WordPress are free of spyware, malware, adware, and virus infections. Run secure, stable versions of your applications.
For example, none of the other advice here is worthwhile if malicious software running on your desktop system transmits your server passwords to the enemy.
WordPress could have vulnerabilies as a result of how the program is written that allow an attacker to compromise the security of your server. This can be done by requesting improperly handled querystrings, bad HTTP arguments, form input, etc. If WordPress does not handle the request properly, it could lead to a security issue.
There are two ways to deal with these potential problems:
The WordPress developers do not maintain security patches for older WordPress versions. Once a new version has been released or the vulnerability has been fixed then the information required to exploit the vulnerability is almost certainly in the public domain, making any old versions more open to attack by a 7-year-old with Google and a penchant for mischeif.
The latest stable version of WordPress is always available via the main WordPress website. The official stable release is not available from other sites -- do not install from a location that is not provided from the main WordPress site.
Use the WordPress Dashboard to keep informed about security issues in WordPress should they arise. By the time these issues appear on the Dashboard, a fix should be available for download. Read the entry in the Dashboard or the WordPress Developer Blog to determine what steps you must take to remain secure.
If you find what you think is a bug, report it. See Submitting Bugs for more information and the process. You might have uncovered a vulnerability, or a bug that could lead to one.
If you think you have found a serious security flaw email firstname.lastname@example.org with the information first. The extra time you save in not publicizing the flaw could buy the developers enough time to publish their patch and maintain security on many servers.
The webserver running WordPress, the database with the WordPress data, PHP and any other scripting/programming language used for plugins or helper apps could have vulnerabilities. Therefore, make sure you are running secure, stable versions of your web server, database, scripting interpreter, or make sure you are using a trusted host that takes care of these things for you.
Disable those functions on your server that are unused. If a piece of software is not needed for your entire server, do not install it. Turn off services and daemons that you don't need. Regardless of whether these services are used by you, they can offer a weak spot that can be exploited.
For the services that must run to enable your server's functionality, be sure you have locked them down. If a program should not be initiated from the web, be sure that this program cannot be accessed by the user account allocated for your web server.
With whatever file transfer system you use for deploying files to your server, be sure to limit the access that the transferring account has. For example, an FTP login account used for uploading files to a public web site directory should not also have access to read or write files from anywhere else on the server. The permissions on the account should contain it within a designated area of operations.
The Internet is an insecure place by nature.
The network on both ends -- the WordPress server side and the client network side -- should be trusted. That means updating firewall rules on your home router and being careful about what networks you work from. A busy Internet cafe where you are sending passwords in cleartext over an unencrypted wireless connection is not a trusted network . For example, if you blog by email, consider securing access to your blog over ssh tunnels. Your host should make ure their network is not poisoned by hackers, and you should do the same. Network vulnerabilities allow passwords to be intercepted via sniffers and other sorts of havoc (such as man-in-the-middle attacks) to happen.
If you use FTP to transfer files to your system, consider using SFTP instead. Unlike SFTP, plain FTP transmits your password in clear text, and can be easily intercepted! Also, any file transmissions are unencrypted, and if these files contain login information (such as an uploaded wp-config.php file), they could provide easy access to your server if intercepted. Other possibly more secure solutions than using vanilla FTP include SCP or tunneling FTP or rsync through SSH.
If you access the shell account to execute commands on your server remotely, you should consider using an SSH client. Like FTP, telnet sends and receives everything in clear text that can be intercepted at any point between the client and the server. Depending on your server configuration, using SSH may also enable secure tunneling. Secure tunneling allows a typically insecure protocol (like FTP) to operate through an encrypted transmission tunnel between your desktop and the server.
Some vulnerabilities can be avoided by good security habits. An important element of this is choosing a password.
Things to avoid when choosing a password:
Your goal with your password is to make it as difficult as possible for a human to guess or for a computer to generate algorithmically. Using numbers and varying capitalization make it more difficult statistically to determine a password by brute force. Choosing a password that is hard to guess is particularly important if you do not rename the administrator account.
In that case half the puzzle is already solved for malicious users as they know what username will give them significant privileges to edit files and databases. The Automatic Password Generator can be helpful in generating reasonably complex passwords.
Some of WordPress' cool features come from allowing some files to be writable by web server. However, letting an application have write access to your files is a dangerous thing, particularly in a public environment. A malicious user could find a way to exploit poorly configured permissions, allowing them to alter files on your server and gain control over it.
It is best, from a security perspective, to lock down your file permissions as much as possible and to loosen those restrictions on the occasions that you need to allow write access, or to create special folders with more lax restrictions for the purpose of doing things like uploading images.
Here is one possible permission scheme.
All files should be owned by your user account, and should be writable by you. Any file that needs write access from WordPress should be group-owned by the user account used by the webserver.
Each file to which you allow writable access could provide an additional vector of entry for a malicious user. Keeping the number of files with write access to a minimum can reduce this risk.
Be especially careful with the .htaccess file, since it contains directives that control Apache's behavior, and could be used very easily to exploit your server. Recent updates in WordPress running on recent server software should make it unnecessary to leave this file writable except for the first time it is modified. Usually this is affected by adding new Pages to WordPress. If you set your .htaccess to read-only and are still able to create and view Pages via WordPress, then it's likely you do not need a persistently writeable .htaccess.
When in doubt, restrict permissions. You can always go back and increase permissions later, having only been temporarily inconvenienced. If someone gains access because the permissions were too loose, you could already have lost everything on that machine, maybe others.
Like your server itself, your MySQL database is secured by usernames and passwords. Using a different username and password for your database than for your server or for your WordPress admin user might help reduce the damage caused if one type of account is compromised.
If you run multiple blogs on the same server, it is wise to consider keeping them in separate databases each managed by a different database login. This is best accomplished when performing the initial WordPress installation. This is a containment strategy: If an intruder successfully cracks one of WordPress installation, this makes it that much harder to alter your other blogs.
If you administer MySQL yourself, ensure that you understand your MySQL configuration and that unneeded features (such as accepting remote TCP connections) are disabled. See Secure MySQL Database Design for a nice introduction.
A common type of problem in relation to database security is SQL insertion. Unsecure scripts can allow malicious users to insert extra commands into a statement executed on your database. Using clever methods, these statements could add new users to your blog with high permissions, allowing them to make changes to your site or worse.
WordPress developers endeavor to eliminate these vulnerabilities in the WordPress source, but WordPress is not the only vector for these attacks. Be sure that the authors of other software and scripts that you run on your site have taken the steps necessary to reduce the likelihood of this kind of attack.
An extension module for Apache called mod_security is available to help reduce the risk of this type of attack. While modules such as these aren't foolproof, they do offer an extra layer of protection in the case that an undiscovered or unpatched vulnerability exists.
First, we need to dispense with a major myth: A login page implies a secure administrative area. A login page does not mean a secure administrative area. Restricting access via a simple login is not the most secure method of locking users out of your WordPress administration area, because the connection between you and your admin area is still insecure. An attacker using a man-in-the-middle technique could poison your communications with your server, or could obtain from your own computer the cookies that WordPress uses to keep you logged in. An attacker that has this information would not know your password, but could craft a cookie that would convince WordPress that they were you.
The following discussion on securing the wp-admin area to enable access over SSL describes a number of ways of protecting your administration area. Methods like this provide additional layers of security for your login by encrypting the transmission between your browser and the server.
If a plugin wants write access to your WordPress files and directories, please read the code to make sure it is legit or check with someone you trust. Possible places to check are the Support Forums and IRC Channel.
Part of the goal of hardening WordPress is containing the damage done if there is a successful attack. Plugins that allow arbitrary PHP or other code to execute from entries in a database effectively magnify the possibility of damage in the event of a successful attack. As an example of how far-reaching this security issue is, assuming that a malicious user only has access to modify database entries, allowing anyone to execute code from the database, such a user could insert code that gives them much more control over the server, possibly capturing credentials of users with more permissions.
Security through obscurity is typically thought to be an unsound primary strategy. However, there are areas in WordPress where obscuring a bit could help with security:
If you are running an old WordPress version with known vulnerabilities, it is unwise to display this information to the public. Why not simply hide the WordPress version entirely? Even if you update packages as quickly as you can, there will be lag between the version release and your deployment, potentially enough time for a malicious person to carry out an attack.
Editing out all the places where WordPress advertises its version string in your theme can be a pain, but it might be worth it to hunt down. WordPress typically stores the version number in a variable named $wp_version. Searching for this variable in your theme templates might help you remove the version notices. It will not be useful to remove the version number from the /wp-includes/version.php file, since you should upgrade to the most recent stable release rather than tweak this number.
It is still always best to make sure you are running the latest WordPress version.
The security implication here is that an account is likely to exist in your WordPress installation that has administrative powers, and the username of this login account is well known, "admin". Changing the default admin username might help mitigate the possibility of an attacker using it to compromise your system.
The WordPress admin account is difficult to manage, since you cannot change the admin username via the user editor in WordPress, nor can you reduce the admin user permissions below the maximum. In the case that you want to change the administrator's account name (this is 'admin' in a default WordPress installation), you can do so by modifying the users table directly using a database editing tool such as phpMyAdmin, or by executing the following query directly in MySQL, replacing "new_username" with the username of your choice:
UPDATE wp_users SET user_login = 'new_username' WHERE user_login = 'admin';
This will only work if your username is currently the default value of "admin". But you can change your current username by changing the "admin" part of this query to your current username.
If you want a simple way to fix the Admin account issue - direct from the Wordpress Admin panel... here goes. (you will "ideally" require 2 email addresses)
1) Create a new user with admin rights. Wordpress will insist that this new user has a different email address to the default 'admin' account. If you do not have 2 email addresses then create an imaginary one as follows email@example.com - where mydomain.com is the domain you are hosting your wordpress blog on.
2) Logout of the 'admin' account and then log back in as your new user.
3) Delete the 'admin' account. Because your new user also has admin rights, then Wordpress will allow this.
4) For those who didn't have 2 email addresses...
4a) Now change the email address for your new user. Since the original 'admin' was deleted, Wordpress will now allow you to use that email address for your new account.
4b) Now change the password for the new user - remember that you made-up an imaginary email address... well the password for the new user was sent to that address. Best to change that password now - just incase someone actually received that email!
Thats it! All done. Now you have an admin account without the default name 'admin'.
Backup your data regularly, including your MySQL databases (see Backing_Up_Your_Database). Data integrity is critical for trusted backups. Encrypting the backup, keeping an independent record of MD5 hashes for each backup file, and/or placing backups on read-only media (such as CD-R) increases your confidence that your data has not been tampered with.
A sound backup strategy could include keeping a set of regularly-timed snapshots of your entire WordPress installation (including WordPress core files and your database) in a trusted location. Imagine a site that makes weekly snapshots. Such a strategy means that if a site is compromised on May 1st but the compromise is not detected until May 12th, the site owner will have pre-compromise backups that can help in rebuilding the site and possibly even post-compromise backups which will aid in determining how the site was compromised.
You should consider keeping copies of your backups offline or on another server in the case of catastrophic server failure. Remember, security is not compromised only by intruders but by failed equipment. In this case, you would be able to restore your server with more ease than if the backups are located solely on your server.