This article is not the ultimate quick fix to your security concerns. If you have specific security concerns or doubts, you should discuss them with people whom you trust to have sufficient knowledge of computer security and WordPress.

What is Security?

Fundamentally, security is not about perfectly secure systems. Such a thing might well be impractical, or impossible to find and/or maintain. What security is though is risk reduction, not risk elimination. It’s about employing all the appropriate controls available to you, within reason, that allow you to improve your overall posture reducing the odds of making yourself a target, subsequently getting hacked.

Website Hosts

Often, a good place to start when it comes to website security is your hosting environment. Today, there are a number of options available to you, and while hosts offer security to a certain level, it’s important to understand where their responsibility ends and yours begins. Here is a good article explaining the complicated dynamic between web hosts and the security of your website. A secure server protects the privacy, integrity, and availability of the resources under the server administrator’s control.

Qualities of a trusted web host might include:

• Readily discusses your security concerns and which security features and processes they offer with their hosting.
• Provides the most recent stable versions of all server software.
• Provides reliable methods for backup and recovery.

Decide which security you need on your server by determining the software and data that needs to be secured. The rest of this guide will help you with this.

Website Applications

It’s easy to look at web hosts and pass the responsibility of security to them, but there is a tremendous amount of security that lies on the website owner as well. Web hosts are often responsible for the infrastructure on which your website sits, they are not responsible for the application you choose to install.

To understand where and why this is important you must understand how websites get hacked, Rarely is it attributed to the infrastructure, and most often attributed to the application itself (i.e., the environment you are responsible for).

Security Themes

Keep in mind some general ideas while considering security for each aspect of your system:

Limiting access

Making smart choices that reduce possible entry points available to a malicious person.

Containment

Your system should be configured to minimize the amount of damage that can be done in the event that it is compromised.

Preparation and knowledge

Keeping backups and knowing the state of your WordPress installation at regular intervals. Having a plan to backup and recover your installation in the case of catastrophe can help you get back online faster in the case of a problem.

Trusted Sources

Do not get plugins/themes from untrusted sources. Restrict yourself to the WordPress.org repository or well known companies. Trying to get plugins/themes from the outside may lead to issues.

Vulnerabilities on Your Computer

Make sure the computers you use are free of spyware, malware, and virus infections. No amount of security in WordPress or on your web server will make the slightest difference if there is a keylogger on your computer.

Always keep your operating system and the software on it, especially your web browser, up to date to protect you from security vulnerabilities. If you are browsing untrusted sites, we also recommend using tools like no-script (or disabling javascript/flash/java) in your browser.

Vulnerabilities in WordPress

Like many modern software packages, WordPress is updated regularly to address new security issues that may arise. Improving software security is always an ongoing concern, and to that end you should always keep up to date with the latest version of WordPress. Older versions of WordPress are not maintained with security updates.

Updating WordPress

Main article: Updating WordPress.

The latest version of WordPress is always available from the main WordPress website at https://wordpress.org. Official releases are not available from other sites — never download or install WordPress from any website other than https://wordpress.org.

Since version 3.7, WordPress has featured automatic updates. Use this functionality to ease the process of keeping up to date. You can also use the WordPress Dashboard to keep informed about updates. Read the entry in the Dashboard or the WordPress Developer Blog to determine what steps you must take to update and remain secure.

If a vulnerability is discovered in WordPress and a new version is released to address the issue, the information required to exploit the vulnerability is almost certainly in the public domain. This makes old versions more open to attack, and is one of the primary reasons you should always keep WordPress up to date.

If you are an administrator in charge of more than one WordPress installation, consider using Subversion to make management easier.

Reporting Security Issues

If you think you have found a security flaw in WordPress, you can help by reporting the issue. See the Security FAQ for information on how to report security issues.

If you think you have found a bug, report it. See Submitting Bugs for how to do this. You might have uncovered a vulnerability, or a bug that could lead to one.

Web Server Vulnerabilities

The web server running WordPress, and the software on it, can have vulnerabilities. Therefore, make sure you are running secure, stable versions of your web server and the software on it, or make sure you are using a trusted host that takes care of these things for you.

If you’re on a shared server (one that hosts other websites besides your own) and a website on the same server is compromised, your website can potentially be compromised too even if you follow everything in this guide. Be sure to ask your web host what security precautions they take.

Network Vulnerabilities

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. An Internet cafe where you are sending passwords over an unencrypted connection, wireless or otherwise, is not a trusted network.

Your web host should be making sure that their network is not compromised by attackers, and you should do the same. Network vulnerabilities can allow passwords and other sensitive information to be intercepted.

Passwords

Many potential vulnerabilities can be avoided with good security habits. A strong password is an important aspect of this.

The goal with your password is to make it hard for other people to guess and hard for a brute force attack to succeed. Many automatic password generators are available that can be used to create secure passwords.

WordPress also features a password strength meter which is shown when changing your password in WordPress. Use this when changing your password to ensure its strength is adequate.

Things to avoid when choosing a password:

• Any permutation of your own real name, username, company name, or name of your website.
• A word from a dictionary, in any language.
• A short password.
• Any numeric-only or alphabetic-only password (a mixture of both is best).

A strong password is necessary not just to protect your blog content. A hacker who gains access to your administrator account is able to install malicious scripts that can potentially compromise your entire server.

In addition to using a strong password, it’s a good idea to enable two-step authentication as an additional security measure.

FTP

When connecting to your server you should use SFTP encryption if your web host provides it. If you are unsure if your web host provides SFTP or not, just ask them.

Using SFTP is the same as FTP, except your password and other data is encrypted as it is transmitted between your computer and your website. This means your password is never sent in the clear and cannot be intercepted by an attacker.

File Permissions

Some neat features of WordPress come from allowing various files to be writable by the web server. However, allowing write access to your files is potentially dangerous, particularly in a shared hosting environment.

It is best 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 specific folders with less restrictions for the purpose of doing things like uploading files.

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 writable by the web server, if your hosting set up requires it, that may mean those files need to be group-owned by the user account used by the web server process.

/

The root WordPress directory: all files should be writable only by your user account, except .htaccess if you want WordPress to automatically generate rewrite rules for you.

/wp-admin/

The WordPress administration area: all files should be writable only by your user account.

/wp-includes/

The bulk of WordPress application logic: all files should be writable only by your user account.

/wp-content/

User-supplied content: intended to be writable by your user account and the web server process.

Within /wp-content/ you will find:

/wp-content/themes/

Theme files. If you want to use the built-in theme editor, all files need to be writable by the web server process. If you do not want to use the built-in theme editor, all files can be writable only by your user account.

/wp-content/plugins/

Plugin files: all files should be writable only by your user account.

Other directories that may be present with /wp-content/ should be documented by whichever plugin or theme requires them. Permissions may vary.

Changing file permissions

If you have shell access to your server, you can change file permissions recursively with the following command:

For Directories:

find /path/to/your/wordpress/install/ -type d -exec chmod 755 {} \;

For Files:

find /path/to/your/wordpress/install/ -type f -exec chmod 644 {} \;

Regarding Automatic Updates

When you tell WordPress to perform an automatic update, all file operations are performed as the user that owns the files, not as the web server’s user. All files are set to 0644 and all directories are set to 0755, and writable by only the user and readable by everyone else, including the web server.

Database Security

If you run multiple blogs on the same server, it is wise to consider keeping them in separate databases each managed by a different user. This is best accomplished when performing the initial WordPress installation. This is a containment strategy: if an intruder successfully cracks one 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.

Restricting Database User Privileges

For normal WordPress operations, such as posting blog posts, uploading media files, posting comments, creating new WordPress users and installing WordPress plugins, the MySQL database user only needs data read and data write privileges to the MySQL database; SELECT, INSERT, UPDATE and DELETE.

Therefore any other database structure and administration privileges, such as DROP, ALTER and GRANT can be revoked. By revoking such privileges you are also improving the containment policies.

Note: Some plugins, themes and major WordPress updates might require to make database structural changes, such as add new tables or change the schema. In such case, before installing the plugin or updating a software, you will need to temporarily allow the database user the required privileges.

WARNING: Attempting updates without having these privileges can cause problems when database schema changes occur. Thus, it is NOT recommended to revoke these privileges. If you do feel the need to do this for security reasons, then please make sure that you have a solid backup plan in place first, with regular whole database backups which you have tested are valid and that can be easily restored. A failed database upgrade can usually be solved by restoring the database back to an old version, granting the proper permissions, and then letting WordPress try the database update again. Restoring the database will return it back to that old version and the WordPress administration screens will then detect the old version and allow you to run the necessary SQL commands on it. Most WordPress upgrades do not change the schema, but some do. Only major point upgrades (3.7 to 3.8, for example) will alter the schema. Minor upgrades (3.8 to 3.8.1) will generally not. Nevertheless, keep a regular backup.

Securing wp-admin

Adding server-side password protection (such as BasicAuth) to /wp-admin/ adds a second layer of protection around your blog’s admin area, the login screen, and your files. This forces an attacker or bot to attack this second layer of protection instead of your actual admin files. Many WordPress attacks are carried out autonomously by malicious software bots.

Simply securing the wp-admin/ directory might also break some WordPress functionality, such as the AJAX handler at wp-admin/admin-ajax.php. See the Resources section for more documentation on how to password protect your wp-admin/ directory properly.

The most common attacks against a WordPress blog usually fall into two categories.

1. Sending specially-crafted HTTP requests to your server with specific exploit payloads for specific vulnerabilities. These include old/outdated plugins and software.
2. Attempting to gain access to your blog by using “brute-force” password guessing.

The ultimate implementation of this “second layer” password protection is to require an HTTPS SSL encrypted connection for administration, so that all communication and sensitive data is encrypted. See Administration Over SSL.

Securing wp-includes

A second layer of protection can be added where scripts are generally not intended to be accessed by any user. One way to do that is to block those scripts using mod_rewrite in the .htaccess file. Note: to ensure the code below is not overwritten by WordPress, place it outside the # BEGIN WordPress and # END WordPress tags in the .htaccess file. WordPress can overwrite anything between these tags.

# Block the include-only files.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^wp-admin/includes/ - [F,L]
RewriteRule !^wp-includes/ - [S=3]
RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
RewriteRule ^wp-includes/theme-compat/ - [F,L]
</IfModule>


# BEGIN WordPress

Note that this won’t work well on Multisite, as RewriteRule ^wp-includes/[^/]+\.php$ - [F,L] would prevent the ms-files.php file from generating images. Omitting that line will allow the code to work, but offers less security.

Securing wp-config.php

You can move the wp-config.php file to the directory above your WordPress install. This means for a site installed in the root of your webspace, you can store wp-config.php outside the web-root folder.

Note: Some people assert that moving wp-config.php has minimal security benefits and, if not done carefully, may actually introduce serious vulnerabilities. Others disagree.

Note that wp-config.php can be stored ONE directory level above the WordPress (where wp-includes resides) installation. Also, make sure that only you (and the web server) can read this file (it generally means a 400 or 440 permission).

If you use a server with .htaccess, you can put this in that file (at the very top) to deny access to anyone surfing for it:

<files wp-config.php>
order allow,deny
deny from all
</files>

Disable File Editing

The WordPress Dashboard by default allows administrators to edit PHP files, such as plugin and theme files. This is often the first tool an attacker will use if able to login, since it allows code execution. WordPress has a constant to disable editing from Dashboard. Placing this line in wp-config.php is equivalent to removing the ‘edit_themes’, ‘edit_plugins’ and ‘edit_files’ capabilities of all users:

define('DISALLOW_FILE_EDIT', true);

This will not prevent an attacker from uploading malicious files to your site, but might stop some attacks.

Plugins

First of all, make sure your plugins are always updated. Also, if you are not using a specific plugin, delete it from the system.

Firewall

There are many plugins and services that can act as a firewall for your website. Some of them work by modifying your .htaccess
file and restricting some access at the Apache level, before it is processed by WordPress. A good example is iThemes Security or All in One WP Security. Some firewall plugins act at the WordPress level, like WordFence and Shield, and try to filter attacks as WordPress is loading, but before it is fully processed.

Besides plugins, you can also install a WAF (web firewall) at your web server to filter content before it is processed by WordPress. The most popular open source WAF is ModSecurity.

A website firewall can also be added as intermediary between the traffic from the internet and your hosting server. These services all function as reverse proxies, in which they accept the initial requests and reroute them to your server, stripping it of all malicious requests. They accomplish this by modifying your DNS records, via an A record or full DNS swap, allowing all traffic to pass through the new network first. This causes all traffic to be filtered by the firewall before reaching your site. A few companies offer such service, like CloudFlare, Sucuri and Incapsula.

Additionally, these third parties service providers function as Content Distribution Network (CDNs) by default, introducing performance optimization and global reach.

Plugins that need write access

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.

Code execution plugins

As we said, part of the goal of hardening WordPress is containing the damage done if there is a successful attack. Plugins which 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.

A way to avoid using such a plugin is to use custom page templates that call the function. Part of the security this affords is active only when you disallow file editing within WordPress.

Security through obscurity

Security through obscurity is generally an unsound primary strategy. However, there are areas in WordPress where obscuring information might help with security:

1. Rename the administrative account: When creating an administrative account, avoid easily guessed terms such as admin or webmaster as usernames because they are typically subject to attacks first. On an existing WordPress install you may rename the existing account in the MySQL command-line client with a command like UPDATE wp_users SET user_login = 'newuser' WHERE user_login = 'admin';, or by using a MySQL frontend like phpMyAdmin.
2. Change the table_prefix: Many published WordPress-specific SQL-injection attacks make the assumption that the table_prefix is wp_, the default. Changing this can block at least some SQL injection attacks.

Data Backups

Back up your data regularly, including your MySQL databases. See the main article: 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 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.

Logging

Logs are your best friend when it comes to understanding what is happening with your website, especially if you’re trying to perform forensics. Contrary to popular beliefs, logs allow you to see what was done and by who and when. Unfortunately the logs will not tell you who, username, logged in, but it will allow you to identify the IP and time and more importantly, the actions the attacker might have taken. You will be able to see any of these attacks via the logs – Cross Site Scripting (XSS), Remote File Inclusion (RFI), Local File Inclusion (LFI) and Directory Traversal attempts. You will also be able to see brute force attempts. There are various examples and tutorials available to help guide you through the process of parsing and analyzing your raw logs.

If you get more comfortable with your logs you’ll be able to see things like, when the theme and plugin editors are being used, when someone updates your widgets and when posts and pages are added. All key elements when doing forensic work on your web server. The are a few WordPress Security plugins that assist you with this as well, like the Sucuri Auditing tool or the Audit Trail plugin.

There are two key open-source solutions you’ll want on your web server from a security perspective, this is a layered approach to security.

OSSEC can run on any NIX distribution and will also run on Windows. When configured correctly its very powerful. The idea is correlate and aggregate all the logs. You have to be sure to configure it to capture all access_logs and error_logs and if you have multiple websites on the server account for that. You’ll also want to be sure to filter out the noise. By default you’ll see a lot of noise and you’ll want to configure it to be really effective.

Monitoring

Sometimes prevention is not enough and you may still be hacked. That’s why intrusion detection/monitoring is very important. It will allow you to react faster, find out what happened and recover your site.

Monitoring your logs

If you are on a dedicated or virtual private server, in which you have the luxury of root access, you have the ability easily configure things so that you can see what’s going on. OSSEC easily facilitates this and here is a little write up that might help you out OSSEC for Website Security – Part I.

Monitoring your files for changes

When an attack happens, it always leave traces. Either on the logs or on the file system (new files, modified files, etc). If you are using OSSEC for example, it will monitor your files and alert you when they change.

Goals

The goals of file system tracking include:

• Monitor changed and added files
• Log changes and additions
• Ability to revert granular changes
• Automated alerts

General approaches

Administrators can monitor file system via general technologies such as:

• System utilities
• Revision control
• OS/kernel level monitoring

Specific tools

Options for file system monitoring include:

• diff – build clean test copy of your site and compare against production
• Git – source code management
• inotify and incron – OS kernel level file monitoring service that can run commands on filesystem events
• Watcher – Python inotify library
• OSSEC – Open Source Host-based Intrusion Detection System that performs log analysis, file integrity checking, policy monitoring, rootkit detection, real-time alerting and active response.

Considerations

When configuring a file based monitoring strategy, there are many considerations, including the following.

Run the monitoring script/service as root

This would make it hard for attackers to disable or modify your file system monitoring solution.

Disable monitoring during scheduled maintenance/upgrades

This would prevent unnecessary notifications when you are performing regular maintenance on the site.

Monitor only executable filetypes

It may be reasonably safe to monitor only executable file types, such as .php files, etc.. Filtering out non-executable files may reduce unnecessary log entries and alerts.

Use strict file system permissions

Read about securing file permissions and ownership. In general, avoid allowing execute and write permissions to the extent possible.

Monitoring your web server externally

If the attacker tries to deface your site or add malware, you can also detect these changes by using a web-based integrity monitor solution. This comes in many forms today, use your favorite search engine and look for Web Malware Detection and Remediation and you’ll likely get a long list of service providers.

Resources

• How to Improve WordPress Security (Infographic)
• Security Plugins
• WordPress Security Cutting Through the BS
• e-Book: Locking Down WordPress
• wpsecure.net has a few guides on how to lock down WordPress.
• A Beginners Guide to Hardening WordPress
• Brad Williams: Lock it Up (Video)
• 21 Ways to Secure Your WordPress Site
• Official docs on how to password protect directories with an .htaccess file
• Simple tutorial on how to password protect the WordPress admin area and fix the 404 error

See Also

• Security FAQ
• FAQ – My site was hacked
• Brute Force Attacks
• WordPress Security Whitepaper

They are, in short, an attack on the weakest link in any website’s security… you.

Due to the nature of these attacks, you may find your server’s memory goes through the roof, causing performance problems. This is because the number of http requests (that is the number of times someone visits your site) is so high that servers run out of memory.

This sort of attack is not endemic to WordPress, it happens with every webapp out there, but WordPress is popular and thus a frequent target.

Protect Yourself

A common attack point on WordPress is to hammer the wp-login.php file over and over until they get in or the server dies. You can do some things to protect yourself.

Don’t use the ‘admin’ username

The majority of attacks assume people are using the username ‘admin’ due to the fact that early versions of WordPress defaulted to this. If you are still using this username, make a new account, transfer all the posts to that account, and change ‘admin’ to a subscriber (or delete it entirely).

You can also use the plugin Change Username to change your username.

Good Passwords

The goal with your password is to make it hard for other people to guess and hard for a brute force attack to succeed. Many automatic password generators are available that can be used to create secure passwords.

WordPress also features a password strength meter which is shown when changing your password in WordPress. Use this when changing your password to ensure its strength is adequate.

You can use the Force Strong Password plugin to force users to set strong passwords.

Things to avoid when choosing a password:

• Any permutation of your own real name, username, company name, or name of your website.
• A word from a dictionary, in any language.
• A short password.
• Any numeric-only or alphabetic-only password (a mixture of both is best).

A strong password is necessary not just to protect your blog content. A hacker who gains access to your administrator account is able to install malicious scripts that can potentially compromise your entire server.

To further increase the strength of your password, you can enable Two Step Authentication to further protect your blog.

Plugins

There are many plugins available to limit the number of login attempts made on your site. Alternatively, there are also many plugins you can use to block people from accessing wp-admin altogether.

Protect Your Server

If you decide to lock down wp-login.php or wp-admin, you may find you get a 404 or 401 error when accessing those pages. To avoid that, you will need to add the following to your .htaccess file.

ErrorDocument 401 default

You can have the 401 point to 401.html, but the point is to aim it at not WordPress.

For Nginx you can use the error_page directive but must supply an absolute url.

error_page  401  http://example.com/forbidden.html;

On IIS web servers you can use the httpErrors element in your web.config, set errorMode="custom":

<httpErrors errorMode="Custom">
 <error statusCode="401"
 subStatusCode="2"
 prefixLanguageFilePath=""
 path="401.htm"
 responseMode="File" />
</httpErrors>

Password Protect wp-login.php

Password protecting your wp-login.php file (and wp-admin folder) can add an extra layer to your server. Because password protecting wp-admin can break any plugin that uses ajax on the front end, it’s usually sufficient to just protect wp-login.php.

To do this, you will need to create a .htpasswd file. Many hosts have tools to do this for you, but if you have to do it manually, you can use this htpasswd generator. Much like your .htaccess file (which is a file that is only an extension), .htpasswd will also have no prefix.

You can either put this file outside of your public web folder (i.e. not in /public_html/ or /domain.com/, depending on your host), or you can put it in the same folder, but you’ll want to do some extra security work in your .htaccess file if you do.

Speaking of which, once you’ve uploaded the .htpasswd file, you need to tell .htaccess where it’s at. Assuming you’ve put .htpasswd in your user’s home directory and your htpasswd username is mysecretuser, then you put this in your .htaccess:

# Stop Apache from serving .ht* files
<Files ~ "^\.ht">
  Order allow,deny
  Deny from all
</Files>
# Protect wp-login.php
<Files wp-login.php>
  AuthUserFile ~/.htpasswd
  AuthName "Private access"
  AuthType Basic
require user mysecretuser
</Files>

The actual location of AuthUserFile depends on your server, and the ‘require user’ will change based on what username you pick.

If you are using Nginx you can password protect your wp-login.php file using the HttpAuthBasicModule. This block should be inside your server block.

location /wp-login.php {
    auth_basic "Administrator Login";
    auth_basic_user_file .htpasswd;
}

The filename path is relative to directory of nginx configuration file nginx.conf

The file should be in the following format:

  user:pass
  user2:pass2
  user3:pass3

Unfortunately there is no easy way of configuring a password protected wp-login.php on Windows Server IIS. If you use a .htaccess processor like Helicon Ape, you can use the .htaccess example mentioned above. Otherwise you’d have to ask your hosting provider to set up Basic Authentication.

All passwords must be encoded by function crypt(3). You can use an online htpasswd generator to encrypt your password.

Limit Access to wp-login.php by IP

If you are the only person who needs to login to your Admin area and you have a fixed IP address, you can deny wp-login.php (and thus the wp-admin/ folder) access to everyone but yourself via an .htaccess or web.config file. This is often referred to as an IP whitelist.

Note: Beware your ISP or computer may be changing your IP address frequently, this is called dynamic IP addressing, rather than fixed IP addressing. This could be used for a variety of reasons, such as saving money. If you suspect this to be the case, find out out how change your computer’s settings, or contact your ISP to obtain a fixed address, in order to use this procedure.

In all examples you have to replace 203.0.113.15 with your IP address. Your Internet Provider can help you to establish your IP address. Or you can use an online service such as What Is My IP.

Examples for multiple IP addresses are also provided. They’re ideal if you use more than one internet provider, if you have a small pool of IP addresses or when you have a couple of people that are allowed access to your site’s Dashboard.

Create a file in a plain text editor called .htaccess and add:

# Block access to wp-login.php.
<Files wp-login.php>
  order deny,allow
  allow from 203.0.113.15
  deny from all
</Files>

You can add more than one allowed IP address using:

# Block access to wp-login.php.
<Files wp-login.php>
  order deny,allow
  allow from 203.0.113.15
  allow from 203.0.113.16
  allow from 203.0.113.17
  deny from all
</Files>

Are you using Apache 2.4 and Apache module mod_authz_host? Then you have to use a slightly different syntax:

# Block access to wp-login.php.
<Files wp-login.php>
  Require ip 203.0.113.15
</Files>

If you want to add more than one IP address, you can use:

# Block access to wp-login.php.
<Files wp-login.php>
  Require ip 203.0.113.15 203.0.113.16 203.0.113.17
  # or for the entire network:
  # Require ip 203.0.113.0/255.255.255.0
</Files>

For Nginx you can add a location block inside your server block that works the same as the Apache example above.

error_page  403  http://example.com/forbidden.html;
location /wp-login.php {
  allow   203.0.113.15
  # or for the entire network:
  # allow   203.0.113.0/24;
  deny    all;
}

Note that the order of the deny/allow is of the utmost importance. You might be tempted to think that you can switch the access directives order and everything will work. In fact it doesn’t. Switching the order in the above example has the result of denying access to all addresses.

Again, on IIS web servers you can use a web.config file to limit IP addresses that have access. It’s best to add this in an additional <location directive.

<location path="wp-admin">
  <system.webServer>
    <security>
      <ipSecurity allowUnlisted="false"> <!-- this rule denies all IP addresses, except the ones mentioned below -->
        <!-- 203.0.113.x is a special test range for IP addresses -->
        <!-- replace them with your own -->
        <add ipAddress="203.0.113.15" allowed="true" />
        <add ipAddress="203.0.113.16" allowed="true" />
      </ipSecurity>
    </security>
  </system.webServer>
</location>

Deny Access to No Referrer Requests

Extended from Combatting Comment Spam, you can use this to prevent anyone who isn’t submitting the login form from accessing it:

# Stop spam attack logins and comments
<IfModule mod_rewrite.c>
	RewriteEngine On
	RewriteCond %{REQUEST_METHOD} POST
	RewriteCond %{REQUEST_URI} .(wp-comments-post|wp-login)\.php*
	RewriteCond %{HTTP_REFERER} !.*example.com.* [OR]
	RewriteCond %{HTTP_USER_AGENT} ^$
	RewriteRule (.*) http://%{REMOTE_ADDR}/$1 [R=301,L]
</ifModule>

Nginx – Deny Access to No Referrer Requests

location ~* (wp-comments-posts|wp-login)\.php$ {
      if ($http_referer !~ ^(http://example.com) ) {
           return 405;
      }
}

Windows Server IIS – Deny access to no referrer requests:

<rule name="block_comments_without_referer" patternSyntax="ECMAScript" stopProcessing="true">
<match url="(.*)" ignoreCase="true" />
  <conditions logicalGrouping="MatchAll">
    <add input="{URL}" pattern="^/(wp-comments-post|wp-login)\.php" negate="false"/>
    <add input="{HTTP_REFERER}" pattern=".*example\.com.*" negate="true" />
    <add input="{HTTP_METHOD}" pattern="POST" />  </conditions>
  <action type="CustomResponse" statusCode="403" statusReason="Forbidden: Access is denied." statusDescription="No comments without referrer!" />
</rule>

Change example.com to your domain. If you’re using Multisite with mapped domains, you’ll want to change example.com to (example.com|example.net|example4.com) and so on. If you are using Jetpack comments, don’t forget to add jetpack.wordpress.com as referrer: (example.com|jetpack\.wordpress\com)

ModSecurity

If you use ModSecurity, you can follow the advice from Frameloss – Stopping brute force logins against WordPress. This requires root level access to your server, and may need the assistance of your webhost.

If you’re using ModSecurity 2.7.3, you can add the rules into your .htaccess file instead.

Fail2Ban

Fail2ban is a Python daemon that runs in the background. It checks the logfiles that are generated by Apache (or SSH for example), and on certain events can add a firewall rule. It uses a so called filter with a regular expression. If that regular expression happens for example 5 times in 5 minutes, it can block that IP address for 60 minutes (or any other set of numbers).

Installing and setting up Fail2ban requires root access.

Blocklists

It appears that most brute force attacks are from hosts from Russia, Kazachstan and Ukraine. You can choose to block ip-addresses that originate from these countries. There are blocklists available on the internet that you can download. With some shell-scripting, you can then load blockrules with iptables.

You have to be aware that you are blocking legitimate users as well as attackers. Make sure you can support and explain that decision to your customers.

Besides blocklists per country, there are lists with ip-addresses of well-known spammers. You can also use these to block them with iptables. It’s good to update these lists regularly.

Setting up of blocklists and iptables requires root access.

Cloud/Proxy Services

Services like CloudFlare and Sucuri CloudProxy can also help mitigate these attacks by blocking the IPs before they reach your server.

See Also

• Sucuri: Protecting Against WordPress Brute Force Attacks
• How to: Protect WordPress from brute-force XML-RPC attacks
• Liquid Web: ModSecurity Rules To Alleviate Brute Force Attacks
• HostGator: Password Protecting wp-login
• Stopping Brute-force Logins
• Swiss Army Knife for WordPress (SAK4WP) – Free Open Source Tool that can help you protect your wp-login.php and /wp-admin/ but not /wp-admin/admin-ajax.php with one click and much more

Suffering a hack can be one of the more frustrating experiences you’ll have on your online journey. Like most things however, taking a pragmatic approach can help you maintain your sanity. While also moving beyond the issues with as little impact as possible.

A hack is a very ambiguous term, which in it of itself will provide little insights into what exactly happened. To ensure you get the help you need via the forums, be sure to understand the specific symptoms that lead you to believe you’ve been hacked. These are otherwise known as Indicators of Compromise (IoC).

A couple of IoC’s that are clear indicators of a hack include:

• Website is blacklisted by Google, Bing, etc..
• Host has disabled your website
• Website has been flagged for distributing malware
• Readers complaining that their desktop AV’s are flagging your site
• Contacted that your website is being used to attack other sites
• Notice behavior that was not authorized (i.e., creation of new users, etc…)
• You can visibly see that your site has been hacked when you open it in the browser

Not all hacks are created equal, so when engaging in the forums please keep this in mind. If you can better understand the symptoms the teams will be better equipped to provide help.

Below you will find a series of steps that are designed to help you start working through the post-hack process. They are not all encompassing as it would be impractical to account for every scenario, but they are designed to help you think through the process.

Some steps to take

Stay calm.

When addressing a security issue, as a website owner, you’re likely experiencing an undue amount of stress. It’s often the most vulnerable you have found yourself since being on line and it’s contrary to what every one told you, “Hey, WordPress is Easy!!”

The good news is that all is not lost! Yes, you might lose some money. Yes, you might take a hit against your brand. Yes, you will recover from this.

So, yes, take a step back and compose yourself. Doing so will allow you to more effectively take control of the situation and allow you to recover your online presence.

Document.

The first actionable step you should take post-compromise is documentation. Take a moment to document what you’re experiencing, and if possible times. A couple of things you want to keep in mind:

• What are you seeing that leads you to believe you are hacked?
• What time did you notice this issue? What timezone?
• What actions have you taken recently? Was a new plugin installed? Did you make a change to a theme? Modify a widget?

You are creating the baseline for what is recognized as an incident report. Whether you are planning to perform the incident response yourself, or engage a professional organization, this document will prove invaluable over time.

Recommend taking a moment to annotate details of your host environment as well. It will be required at some point during the incident response process.

Scan your website.

When scanning your website you have a few different ways to do this, you can use external remote scanners or application level scanners. Each are designed to look and report on different things. No one solution is the best approach, but together you improve your odds greatly.

Application Based Scanners (Plugins):

• Quttera
• GOTMLS
• WordFence
• Sucuri

Remote Based Scanners (Crawlers):

• VirusTotal
• Sitecheck

There are also a number of other related security plugins available in the WP repo. The ones annotated above have been around a long time and have strong communities behind each of them.

Scan your local environment.

In addition to scanning your website, you should start scanning your local environment. In many instances, the source of the attack / infection begins on your local box (i.e., notebook, desktop, etc…). Attackers are running trojans locally that allow them to sniff login access information to things like FTP and /wp-admin that allow them to log in as the site owner.

Make sure you run a full anti-virus/malware scan on your local machine. Some viruses are good at detecting AV software and hiding from them. So maybe try a different one. This advice extends to both Windows, OS X and Linux machines.

Check with your hosting provider.

The hack may have affected more than just your site, especially if you are using shared hosting. It is worth checking with your hosting provider in case they are taking steps or need to. Your hosting provider might also be able to confirm if a hack is an actual hack or a loss of service, for example.

One very serious implication of a hack these days is around Email blacklisting. This seems to be happening more and more. As websites are abused to send out SPAM emails, Email Blacklist authorities are flagging the website IP’s and those IP’s are often associated with the same server being used for email. The best thing you can do is look at Email providers like Google Apps when it comes to your business needs.

Be Mindful of Website Blacklists.

Google Blacklist issues can be detrimental to your brand. They currently blacklist somewhere in the neighborhood of 9,500 to 10,000 websites a day. This number grows daily. There are various forms of warnings, from large splash pages warning users to stay away, to more subtle warnings that pop up in your Search Engine Result Pages (SERPs).

Although Google is one of the more prominent ones, there are a number of other blacklist entities like Bing, Yahoo and a wide range of Desktop AntiVirus applications. Understand that your clients / website visitors may leverage any number of tools and any one of them could be causing the issue.

It’s recommended that you register your site with the various online webmaster consoles like:

• Google Search Console
• Bing Webmaster
• Yandex Webmaster
• Norton Webmaster

Improve your Access Controls.

You will often hear folks talking about updating things like Passwords. Yes, this is a very important piece, but it’s one small piece in a much larger problem. We need improve our overall posture when it comes to access control. This means using Complex, Long and Unique passwords for starters. The best recommendation is to use a Password Generator like those found in apps like 1Password and LastPass.

Remember that this includes changing all access points. When we say access points we mean things like FTP / SFTP, WP-ADMIN, CPANEL (or any other administrator panel you use with your host) and MYSQL.

This also extends beyond your user, and must include all users that have access to the environment.

It is also recommended to consider using some form of Two Factor / Multi-Factor authentication system. In it’s most basic form, it introduces, and requires, a second form of authentication when logging into your WordPress instance.

Some of the plugins available to assist you with this include:

• Rublon
• Duo

Reset all Access.

Once you identify a hack, one of the first steps you will want to do is lock things down so that you can minimize any additional changes. The first place to start is with your users. You can do this by forcing a global password reset for all users, especially administrators.

Here is a plugin that can assist with this step:

• iThemes Security

You also want to clear any users that might be actively logged into WordPress. You do this by updating the secret keys in wp-config. You will need to create a new set here: the WordPress key generator. Take those values then overwrite the values in your wp-config.php file with the new ones. This will force anyone that might still be logged in off.

Create a Backup.

You hopefully have a backup of your website, but if you don’t, this will be a good time to create one. Backups are a critical piece of your continuation of operations, and should be something you actively plan for moving forward. You should also ask your host what their policy is as it pertains to backups. If you do have a backup, you should be able to perform a restore and skill right into the forensics work.

Side note: It’s important you keep regular backups of your database and files. If this ever happens again.

Regardless, before you move into the next phase of cleaning, it is recommended you take one more snapshot of the environment. Even if it’s infected, depending on the type of hack, the impacts can cause a lot of issues and in the event of catastrophic failure you’ll at least have that bad copy to reference.

Find and remove the hack.

This will be the most daunting part of the entire process. Finding and removing the hack. The exact steps you take will be dictated by a number of factors, including, but not limited to, the symptoms provided above. How you approach the problem will be determined by your own technical aptitude working with websites and web servers.

To help in the process though, we’ve included a number of different resources that should help you in the process:

• Did Your WordPress Site Get Hacked?
• How to Clean Your Hacked Install
• How To Clean a Hacked WordPress Site
• How to Cope With a Hacked Site
• Four Malware Infections
• How to Clean a WordPress Hack

It might be tempting to purge everything and start over. In some cases that’s possible, but in many instances it’s just not possible. What you can do however is reinstall certain elements of the site with little regard to impacting the core of your website. You always want to make sure you reinstall the same version of software your website is using, if you choose an older or newer one you’re likely to kill your website. When reinstalling, be sure not to use the reinstall options in your WP-ADMIN. Use your FTP / SFTP application to drag and drop the versions. This will prove much more effective in the long run as those installers often only overwrite existing files, and hacks often introduce new files… You can replace the following directories safely:

• /wp-admin
• /wp-includes

From there, it’s recommended that you be more diligent in updating and replacing files as you move through wp-content as it contains your theme and plugin files.

The one file you will definitely want to look at is your .htaccess file. It’s one of the more common files, regardless of the type of infection, that is most often updated and used for nefarious activities. This file is often located at the root of your installation folder, but can also be embedded within several other directories on the same installation.

Regardless of the type of infection, there are will be some common files you will want to keep an eye on during your remediation process. They include:

• index.php
• header.php
• footer.php
• function.php

If modified, these files can usually adversely affect all page requests, making them high targets for bad actors.

Leverage the Community

We often forget but we’re a community based platform, this means that if you’re in trouble someone in the community is likely to give a lending hand. A very good place to start if you’re strapped for cash or just looking for a helping hand is the WordPress.org Hacked or Malware forum.

Update!

Once you are clean, you should update your WordPress installation to the latest software. Older versions are more prone to hacks than newer versions.

Change the passwords again!

Remember, you need to change the passwords for your site after making sure your site is clean. So if you only changed them when you discovered the hack, change them again now. Again remembering to use Complex, Long and Unique passwords.

You may consider to change the database user account and password. When you changed them, do not forget enhancing them to wp-config.php file.

Forensics.

Forensics is the process of understanding what happened. How did the attackers get in? The goal is to understand the attack vector a bad actor used to ensure they’re unable to abuse it again. In many instances, it’s very difficult for website owners to perform this type of analysis due to lack of technical knowledge and / or available data. If you do have the metadata required, then there are tools like like OSSEC and splunk that can help you synthesize the data.

Secure your site.

Now that you have successfully recovered your site, secure it by implementing some (if not all) of the recommended security measures.

Can’t Log Into WordPress Admin Panel

There are times that a bad actor will hijack your administrator account[s]. This is not a reason to panic, there are a few different things you can do to regain control of your account. You can follow these steps to reset your password

Tools like phpMyAdmin and Adminer are often made available via your hosting provider. They allow you to log into your database directly, bypassing your Administration Screen and resetting your user in the users table wp_users.

If you don’t want to mess with password hashes or can’t figure it out, simply update your email and go back to Login Screen, click forgot password, and wait for the email.

Using version control?

If you are using version control, it can be very handy to quickly identify what has changed and to rollback to a previous version of the website. From the terminal or command line you can compare your files with the versions stored in the official WordPress repository.

$ svn diff .

Or compare a specific file:

$ svn diff /path/to/filename

Other Resources

• Hacked WordPress Backdoors (OttoPress)
• WordPress Security – Cutting Through the BS (Sucuri)
• Security Posts (Perishable Press)

Note: FORCE_SSL_LOGIN was deprecated in Version 4.0. Please use FORCE_SSL_ADMIN.

To Force SSL Logins and SSL Admin Access

The constant FORCE_SSL_ADMIN can be set to true in the wp-config.php file to force all logins and all admin sessions to happen over SSL.

Example

define('FORCE_SSL_ADMIN', true);

Using a Reverse Proxy

If WordPress is hosted behind a reverse proxy that provides SSL, but is hosted itself without SSL, these options will initially send any requests into an infinite redirect loop. To avoid this, you may configure WordPress to recognize the HTTP_X_FORWARDED_PROTO header (assuming you have properly configured the reverse proxy to set that header).

Example

define('FORCE_SSL_ADMIN', true);
// in some setups HTTP_X_FORWARDED_PROTO might contain 
// a comma-separated list e.g. http,https
// so check for https existence
if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false ) {
   $_SERVER['HTTPS'] = 'on';
}

Further Information

The rest of this article serves as information in case you’re using an older version of WordPress (which ideally you shouldn’t!) or your SSL setup is somewhat different (ie. your SSL certificate is for a different domain).

Sometimes, you want your whole wp-admin to run over a secure connection using the https protocol. Conceptually, the procedure works like this:

1. Set up two virtual hosts with the same url (the blog url), one secure, the other not.
2. On the secure virtual host, set up a rewrite rule that shuttles all non-wp-admin traffic to the insecure site.
3. On the insecure virtual host, set up a rewrite rule that shuttles all traffic to wp-admin to the secure host.
4. Put in a filter (via a plugin) that filters the links in wp-admin so that once activated, administrative links are rewritten to use https and that edits cookies to work only over encrypted connections.

The following guide is for WordPress 1.5 and Apache running mod_rewrite, using rewrite rules in httpd.conf (as opposed to .htaccess files) but could easily be modified to fit other hosting scenarios.

Virtual Hosts

You need a (virtual) host configured for the secure server in addition to the non-secure site. In this example, the secure virtual host uses the same DocumentRoot as the insecure host. Hypothetically, you could use a host with a different name, such as wpadmin.mysite.com and link the document root to the wpadmin directory.

Please ask your ISP to set up a secure virtual host for you, or if you have administrative access set up your own. Note that you cannot use name based virtual hosting to identify different SSL servers.

Rewrite Rules For The Insecure Host

In the .htaccess or virtual host stanza in httpd.conf for your insecure host, add this rewrite rule to automatically go to the secure host when you browse to http://mysite.com/wp-admin/ or http://mysite.com/wp-login.php

This should go above the main wordpress rewrite block.

  RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /(.*)\ HTTP/ [NC]
  RewriteCond %{HTTPS} !=on [NC]
  RewriteRule ^/?(wp-admin/|wp-login\.php) https://mysite.com%{REQUEST_URI}%{QUERY_STRING} [R=301,QSA,L]

If you are using permalink rewrite rules, this line must come before RewriteRule ^.*$ - [S=40].

An important idea in this block is using THE_REQUEST, which ensures only actual http requests are rewritten and not local direct file requests, like an include or fopen.

Rewrite Rules For Secure Host (Optional)

These rewrite rules are optional. They disable access to the public site over a secure connection. If you wish to remain logged in to the public portion of your site using the plugin below, you must not add these rules, as the plugin disables the cookie over unencrypted connections.

The secure virtual host should have two rewrite rules in an .htaccess file or in the virtual host declaration (see Using Permalinks for more on rewriting):

   RewriteRule !^/wp-admin/(.*) - [C]
   RewriteRule ^/(.*) http://www.mysite.com/$1 [QSA,L]

The first rule excludes the wp-admin directory from the next rule, which shuffles traffic to the secure site over to the insecure site, to keep things nice and seamless for your audience.

Setting WordPress URI

For some plugins to work, and for other reasons, you may wish to set your WordPress URI in options to reflect the https protocol by making this setting https://mysite.com. Your blog address should not change.

Example Config Stanzas

NOTE: The below config is not 100% compatible with WordPress 2.8+, WordPress 2.8 uses some files from the wp-includes folder. The redirection that the first set of Rewrite rules introduces may cause security warnings for some users. See https://core.trac.wordpress.org/ticket/10079 for more information.

<VirtualHost nnn.nnn.nnn.nnn:443>
        ServerName www.mysite.com

        SSLEngine On
        SSLCertificateFile    /etc/apache2/ssl/thissite.crt
        SSLCertificateKeyFile /etc/apache2/ssl/thissite.pem
        SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown

        DocumentRoot /var/www/mysite

        <IfModule mod_rewrite.c>
                RewriteEngine On
                RewriteRule !^/wp-(admin|includes)/(.*) - [C]
                RewriteRule ^/(.*) http://www.mysite.com/$1 [QSA,L]
        </IfModule>
        ...
</VirtualHost>

# Insecure site
<VirtualHost *>
        ServerName www.mysite.com

        DocumentRoot /var/www/ii/mysite

        <Directory /var/www/ii/mysite >
                <IfModule mod_rewrite.c>
                        RewriteEngine On
                        RewriteBase /
                        RewriteCond %{REQUEST_FILENAME} -f [OR]
                        RewriteCond %{REQUEST_FILENAME} -d
                        RewriteRule ^wp-admin/(.*) https://www.mysite.com/wp-admin/$1 [C]
                        RewriteRule ^.*$ - [S=40]
                        RewriteRule ^feed/(feed|rdf|rss|rss2|atom)/?$ /index.php?&feed=$1 [QSA,L]
                        ...
                </IfModule>
         </Directory>
         ...
</VirtualHost>

Rewrite for Login and Registration

It is probably a good idea to utilize SSL for user logins and registrations. Consider the following substitute RewriteRules.

Insecure

RewriteRule ^/wp-(admin|login|register)(.*) https://www.mysite.com/wp-$1$2 [C]

Secure

RewriteRule !^/wp-(admin|login|register)(.*) - [C]

Rewrite for sites running on port 443 or port 80

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /

# For a site running on port 443 or else (http over ssl)
RewriteCond %{SERVER_PORT}  !^80$
RewriteRule !^wp-(admin|login|register)(.*) - [C]
RewriteRule ^(.*)$ http://%{SERVER_NAME}/$1 [L]

# For a site running on port 80 (http)
RewriteCond %{SERVER_PORT}  ^80$
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^wp-(admin|login|register)(.*) https://%{SERVER_NAME}:10001/wp-$1$2 [L]

RewriteCond %{SERVER_PORT}  ^80$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

</IfModule>

Summary

This method does not fix some inherent security risks in WordPress, nor does it protect you against man-in-the-middle attacks or other risks that can cripple secure connections.

However, this should make it much harder for a malicious person to steal your cookies and/or authentication headers and use them to impersonate you and gain access to wp-admin. It also obfuscates the ability to sniff your content, which could be important for legal blogs which may have drafts of documents that need strict protection.

Verification

On the author’s server, logs indicate that both GET and POST requests are over SSL and that all traffic to wp-admin on the insecure host is being shuttled over to the secure host.

Sample POST log line:

[Thu Apr 28 09:34:33 2005] [info] Subsequent (No.5) HTTPS request received for child 6 (server foo.com:443)
xx.xxx.xxx.xxx - - [28/Apr/2005:09:34:33 -0500] "POST /wp-admin/post.php HTTP/1.1" 302 - "https://foo.com/wp-admin/post.php?acti
on=edit&post=71" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3"

More testing, preferably with a packet sniffer and some hardcore network analysis tools, would help to confirm.

Limitations

The author assumes (but hasn’t checked) that if the user has stored cookies/told their browser to remember passwords (not based on form fields but if using certain external auth mechanism) and hits http://www.mysite.com/wp-admin/, those packets are sent in the clear and the cookie/auth headers could be intercepted. Therefore, to ensure maximum security, the user should explicitly use the https host or always log in at the beginning of new sessions.

Two-step authentication is showing up all over the Internet as more sites look for better ways to secure logins, which are the weakest part of anything a user does online.

What is Two-Step Authentication

Passwords are the de-facto standard for logging in on the web, but they’re relatively easy to break. Even if you make good passwords and change them regularly, they need to be stored wherever you’re logging in, and a server breach can leak them. There are three ways to identify a person, things they are, things they have, and things they know.

Logging in with a password is single-step authentication. It relies only on something you know. Two-step authentication, by definition, is a system where you use two of the three possible factors to prove your identity, instead of just one. In practice, however, current two-step implementations still rely on a password you know, but use your Phone or another device to authenticate with something you have.

Three Possible Factors

There are three possible ways to identify users.

Something You Are

There are a lot of properties that are unique to each user and can be used to identify them. The most popular is fingerprints, but retinas, voice, DNA, or anything else specific to an individual will work. This is called biometric information because these pieces of information all belong to a person’s biology.

Biometric factors are interesting because they are not easily forged and the user can never lose or forget them. However, biometric authentication is tricky because a lost fingerprint can never be replaced. If hackers were to gain access to a database of fingerprints, there is no way that users could reset them or get a new set.

In 2013, Apple released TouchID which lets users unlock their iPhones using their fingerprints. This technology is interesting because the fingerprints are stored locally on the phone, not in the cloud where they would be easier for hackers to steal. There are still trade-offs with this kind of approach, but it is the most widespread consumer use of biometric authentication to date.

Something You Have

Also known as the possession factor, users can be identified by the devices which they carry. Traditionally, a company that wanted to enable two-step authentication would distribute secure keychain fobs to users. The keychain fobs would display a new number every 30 seconds, and that number would be needed to be typed along with the password every time a user logged in.

Modern two-step authentication more frequently relies on a user’s smartphone than on a new piece of hardware. One common model of this uses SMS in order to provide an easy second factor. When the user enters their password, they are sent a text message with a unique code. By entering that code, after the password, they supposedly prove that they also have their phone. Unfortunately, SMS is not a secure communication channel, so smartphone apps and plugins have been developed to create that secure channel.

Something You Know

The most familiar form of authentication is the knowledge factor, or password. As old as Open Sesame, passwords have long been a standard for anonymous authentication. In order for a knowledge factor to work, both parties need to know the password, but other parties must not be able to find or guess it.

The first challenge is in exchanging the password with the trusted party safely. On the web, when you register for a new site, your password needs to be sent to that site’s servers and might be intercepted in the process (which is why you should always check for SSL when registering or logging in — Administration Over SSL).

Once the password has been received, it must be kept secret. The user shouldn’t write it down or use it anywhere else, and the site needs to carefully guard its database to ensure that hackers can’t access the passwords.

Finally, the password needs to be verified. When a user visits the site, they need to be able to provide the password and have it verified against the stored copy. This exchange can also be intercepted (and so should always be done over SSL — Administration Over SSL) and exposes the user to another risk.

Benefits

There are a lot of different places to increase the security of a site, but the WordPress Security Team has said that “The weakest link in the security of anything you do online is your password,” so it makes sense to put energy into strengthening that aspect of your site.

Drawbacks

As the name implies, two-step authentication is adding a step to a process that can already be long and painful. While most very high-security logins are protected by two-step authentication today, most consumer applications barely offer it as an option if they offer it at all. This is because users are less likely to sign up for and log in to a service if it is more difficult.

Two-step authentication can also prevent legitimate logins. If a user forgets their phone at home and has two-step authentication enabled, then they won’t be able to access their account. This is one of the main reasons why smartphones have been useful for two-step authentication — users are more likely to be carrying their phones than almost anything else.

Plugins for Two-Step Authentication

You can search for two-step authentication plugins available in the WordPress.org plugin repository. Here are some of the most popular ones to get you started (in alphabetical order):

• Duo
• Google Authenticator
• Rublon
• Two-Factor
• WordFence

Related

• Brute Force Attacks

So I would suggest you uphold following guidelines when creating a strong password:

• At least 20 characters 
(preferrably more)
• Use lowercase and uppercase
• Containing numbers
• Containing special characters such as a question or an exclamation mark

Example
A good password that upholds all of the guidelines above could be “As32!KoP43??@ZkI??L0d”.

Things You Should Absolutely Avoid

Names or words that can be easily linked to you:

• The name of your partner or kids
• The name of your pet
• The name of your company
• The name of your favorite sports-team or car brand
• The year in which you were born
• Your birthday

All these items are personal (mostly public) information and thus possible risks for social engineering. So avoid these at all cost!

Example

• If you’re name is John Rogers and you were born in 1976, “JohnRogers1976” would be a really bad idea for a password.

Generic password elements:

• Number sequences like “123” or “54321”
• Using generic words like “admin”, “administrator”, “pass”, “password”, “blue”, “house”…

These kind of elements are the first terms that are tried by hackers when attempting to brute force your password, so please avoid these too.

Example
Obviously, the password examples below are horrible passwords and NOT SECURE:

• MattMullenweg2018
• admin123

You should also avoid using the same password on multiple sites or accounts.

Keeping track of your passwords

Since complex passwords are a real necessity these days, it can be a real burden to remember every single password. And thus most people resort to using a password manager to keep track of their different passwords. These password managers actually become a vault for your passwords, secured by one complex master password. They also have functions to automatically (or on your command) enter the stored password for you. This way you only need to remember your one master password to access the password manager vault.

Popular password managers

• 1Password
• Dashlane
• KeePass
• LastPass
• Roboform

Most password managers are a paid service, however if you’re looking for a free solution, you’d might want to check out KeePass.

Depending on your national or international privacy regulations (such as the European Union’s General Data Protection Regulation which may be applicable to you) you may be required to display a privacy policy disclosing your collection and sharing of personal data. Personal data includes things like your users’ name, email, birthdate, phone number, IP address and other data that can be used to identify them.

You may also be required to provide your users with the means to request a copy of the information you hold about them, or request its deletion.

WordPress now includes several simple tools for site administrators to take these steps. These tools make it easier for you to inform your users through a transparent privacy notice about data that is collected on your site. It usually includes at least:

• What data you collect about them,
• Why and how you collect data,
• And what you do with that data (including with whom who you might share that data).

These new tools also make it easier for users to request a copy of their data or its removal. The use of the new data privacy tools (whether required by law or not) will make it easier for you to protect your users’ privacy.

Please note: Every website is different. No two privacy notices will be alike, just as no two site administrators will have identical compliance journeys. Additionally, new regulations, as well as adaptations of existing ones, may alter your compliance journeys. We strongly encourage you to consider that safeguarding privacy is not a one-time responsibility. Taking steps to secure and protect your users’ data is a continuous process both online and offline. These tools can help you with parts of that process, but they are not a compliance process in and of itself. We strongly encourage you to check the regulations and expectations applicable to you and adjust your usage of these tools as needed.

Privacy Settings

This tool makes it easier to select and build a Privacy Policy page. It will create a dedicated page (or adapt an existing one) and provide prompts and headers to kickstart the process.

Site administrators can create this page by going to Settings > Privacy, where the Privacy Policy page setting is managed.

The prompts and headers provided in the tool by default are based on the expectations of Europe’s GDPR as a leading privacy standard. While this gives you a start to build on, your privacy policy is not constrained by this starter text. It is your responsibility to write a comprehensive privacy policy, to ensure that it reflects all national and international legal requirements on privacy, and to keep your policy current and accurate.

Privacy Policy Editing Helper

The Editing Helper feature is part of the new Privacy Settings tool. Drawing information from both WordPress core and a site’s themes and plugins, the Editing Helper pulls together a collected set of default texts which detail a site’s data collection and sharing, generating a starter text which you can use to complete your privacy policy.

While you do not necessarily need to use this tool to build a Privacy Policy, we believe it is helpful because it provides information on how your WordPress site likely collects and processes data in core, theme and plugin code. It is important to consider these back-end uses of data: While not all sites will use all functions (for example, an administrator may choose not to enable comments on posts) nearly every site uses features such as analytics cookies, social media sharing buttons, or contact form plugins. Please add as many additional disclosures as is necessary to be fully transparent about how your site uses personal data.

This tool ONLY collects policy help texts from WordPress and participating plugins. Many sites will also embed third-party tools (such as email subscription services) which collect data in ways the the Editing Helper tool cannot detect, so the default template may not completely describe how your site might collect data about its user. Take the time to understand how your website actually collects your users’ data, and be transparent about what actually happens with data on your website to your users.

Further, theme and plugin developers are invited to learn how the Privacy Policy Editing Helper works, and to feed in the information about how your theme or plugin collects data into the privacy policy tool.

Export Personal Data tool

WordPress now includes a feature to to archive user data for export. This is different from the Tools > Export tool which creates an archive file of posts, pages, or media; the new tool exports in captured elsewhere. You can use this tool by clicking on Tools > Export Personal Data in your WordPress dashboard.

This tool manages email export requests by your users. Following manual approval, it allows you to generate a (.zipformat) file containing the personal data which exists about a user within your WordPress site.

We strongly encourage you use the email validation feature built into the export tools. This confirmation process will help safeguard against abuse, such as malicious users pretending to be someone they are not. As with the Erasure tool, the Erase Personal Data tool uses email validation to send a user’s request to an administrator. The administrator must manually approve the request to send the data in question to the user.

As this tool ONLY gathers data from WordPress and participating plugins, you may need to go beyond to comply with export requests. While it may give you a good start in providing your users with the information they have requested, every site administrator should understand what data they collect and process outside their WordPress site as a full site request may have more responsibility than simply using this export alone.

While this tool’s scope covers much of the scope of WordPress user data, it likely does not include information that may be collected by your site using a third-party service, such as an analytics provider, newsletter subscription service, ad affiliate partner or embedded media.

Erase Personal Data tool

Similar to the Export Personal Data tool, WordPress now includes a tool to delete a user’s personal data upon verified request. You will find this feature under Tools > Erase Personal Data in your WordPress dashboard.

We strongly encourage you use the email validation feature built into the export tool. This confirmation process will help safeguard against abuse, such as malicious users pretending to be someone they are not. As with the Export tool, the Erase Personal Data tool uses email validation to send a user’s request to an administrator. The administrator must manually approve the request to remove the data in question.

Deleted data is permanently removed from the database. Erasure requests cannot be reversed after they have been confirmed. Note that it does not remove the data from backups or archive files: When using the tool alongside automated backups or archives, we advise you to exercise caution when restoring user data from backups. When restoring an archived copy of your site, your requests for erasure should be respected.

As this tool ONLY gathers data from WordPress and participating plugins, you may need to go beyond to comply with erasure requests. While it may give you a good start in complying with your users’ request to remvoe the information they have requested, every site administrator should understand what data they collect and process outside their WordPress site as a full site erasure request may have more responsibility than simply using this tool alone.

In particular (as with the Export tool) it likely does not include information that may be collected by your site using a third-party service, such as an analytics provider, newsletter subscription service, ad affiliate partner or embedded media.

When erasing user data, this tool does not automatically delete registered users and their profile data. Administrators should perform that step themselves after successfully erasing personal data for a registered user. User deletion is available for each user in the Users menu in the Dashboard.

It is also important to understand that personal data deletion requests are not absolute. A site administrator is not obliged to delete data that they may be required to keep for other legal or statutory reasons. For example, you may be required to keep sales records for a certain number of years for tax purposes. You may also wish to keep a user’s records for security purposes, for example, if there is an ongoing investigation into abuse. These situations should be handled internally.

Consent of data collected

Under some privacy laws, you may also be required to have your users’ active, clear, and unambiguous consent before collecting their personal data. Further, you may also be required to have your users’ active, clear, and unambiguous consent before certain kinds of processing of personal data, if that processing isn’t otherwise necessary for your site.

While WordPress.org does not yet have consent tools built, there are various plugins available to help in collecting consent to be compliant with the May 2018 GDPR compliance deadline. In addition, WordPress Core intends to add additional tools for WordPress theme and plugin developers for consent management in WordPress Sites.

Some plugins, especially in the case of forms and email subscription services, suggest that you add a “required” consent field that says something like “I consent to my submitted data being collected and stored” if this is a requirement for your website.

Various notes:

1. To-do: Would be nice if we could add a “how-to-use” section by May 25 launch, see Woo article here doing a good job of this: https://woocommerce.wordpress.com/2018/05/04/woocommerce-3-4-gdpr-features/
2. Note: Leaving in “Explicit Consent” even though we don’t have much to show for it since it’s pragmatically a major concern for major plugins. We should replace with content about WP core when we can.
3. Would like feedback on whether to use link one or two:

• https://wordpress.org/plugins/tags/gdpr
• https://wordpress.org/plugins/gdpr/ Link two is built by a well-respected development shop and does Explicit Consent the way it should be, but link one is less endorsement-heavy.

If a site’s using HTTPS, you’ll see a little padlock icon in the address field, just as in the screenshot below:

Here are the most common reasons you might want to use HTTPS on your own site:

Faster. One might think that HTTPS would make your site slower, since it takes some time to encrypt and decrypt all data. But a lot of efficiency improvements to HTTP are only available when you use HTTPS. As a result, HTTPS will actually make your site faster for almost all visitors.

Trust. Users find it easier to trust a secure site. While they don’t necessarily know their traffic is encrypted, they do know the little padlock icon means a site cares about their privacy. Tech people will know that any servers between your computer and the web server won’t be able to see the information flowing forth and back, and won’t be able to change it.

Payment security. If you sell anything on your site, users want to know their payment information is secure. HTTPS, and the little padlock, assure that their information travels safely to the web server.

Search Engine Optimization. Many search engines will add a penalty to web sites that don’t use HTTPS, thus making it harder to reach the best spots in search results.

Your good name. Have you noticed that some websites have the text “not secure” next to their address?

That happens when your web browser wants you to know a site is NOT using HTTPS. Browsers want you to think (rightly!) that site owners who can’t be bothered using HTTPS (it’s free in many cases) aren’t worth your time and certainly not your money.

In turn, you don’t want browsers suggesting you might be that kind of shady site owner yourself.

To have HTTPS, SSL Certificate is needed to be installed on the server.

Let’s Encrypt is a non-profit organization that provides free SSL certificates for everyone, as of Feb 2020 they have issued over 1 billion certificates. The easiest way to get a certificate is to use the EFF certbot tool, their site has complete instructions for installing and updating certificates for several different web servers and operating systems.

For local development, you can create a self-signed certificate using OpenSSL, however this has limited use since any certificate generated will not be trusted by others, so should only be used for private servers.

There is no extra or special settings needed specifically for WordPress at the web server level for HTTPS. WordPress by default is ready to use HTTPS URLs if the web server is properly configured.

The default port for HTTP URLs is port 80, the default port for HTTPS is port 443. These ports not to be opened through any network firewall. Apache includes a mod_ssl module that needs to be enabled and properly configured. If using certbot, it can automatically configure and create the VirtualHost settings needed. 

Implementing HTTPS for WordPress

To implement HTTPS support on WordPress, you only need to set the WordPress and Site Address URL to use https://. You can install WordPress either using HTTP or HTTPS to start, both will work, and you can switch over later.

 Go to Settings > General and make sure that the WordPress Address (URL) and Site Address (URL) is https. If not, add ‘S’ after http to make https and save it :

The Site health tools (Tools > Site health) will inform you that your website doesn’t use HTTPS.

Since version 5.7, WordPress can also automatically switch to HTTPS if an SSL certificate is already set up on your server.

Best Practices for HTTPS for WordPress

It is recommended for all production WordPress sites to use HTTPS.

• Use a reputable web host, most provide HTTPS service as a standard.
• Use a SSL Certificate from Let’s Encrypt, they are free and easy to use.
• Serve Static Content from an SSL enabled CDN

You may need to redirect your HTTP traffic to your HTTPS site. For Apache, you can do so by creating two VirtualHost entries for example:

<VirtualHost *:80>
    ServerName mkaz.blog
    Redirect / https://mkaz.blog/
</VirtualHost>

<VirtualHost *:443>
    ServerName mkaz.blog
    DocumentRoot /home/mkaz/sites/mkaz.blog
    <Directory /home/mkaz/sites/mkaz.blog>
        Options Indexes FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>

    SSLEngine on
    SSLCertificateFile    /etc/letsencrypt/live/mkaz.blog/cert.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/mkaz.blog/privkey.pem
    SSLCertificateChainFile /etc/letsencrypt/live/mkaz.blog/fullchain.pem
    IncludeOptional /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>

Bad Practices for HTTPS for WordPress

• Serving site from both HTTPS and HTTP urls, use HTTPS and redirect.
• Using mixed content, ie. CSS, JS, or images served from HTTP on an HTTPS page

References and Useful Links

1. Why should I use HTTPS
2. Let’s Encrypt and Certbot
3. Apache Module mod_ssl – Official Apache Module Documentation
4. Encrypting the Web (EFF.org)
5. HTTPS as a ranking signal (Google)
6. Best Practices Securing Your Site (Google)

The only current officially supported version is the last major release of WordPress. Previous major releases before this may or may not get security updates as serious exploits are discovered.

Beta versions, nightly builds, and Subversion check outs are not supported on the WordPress support forums or on the WordPress Documentation.

If you are unable or unwilling to file bug reports, and help fix problems, please do not use anything other than the officially released versions.

Support Policy

Security updates will be backported to older releases when possible, but there are no guarantee and no timeframe for older releases. There are no fixed period of support nor Long Term Support (LTS) version such as Ubuntu’s. None of these are safe to use, except the latest series, which is actively maintained.

For the full list of WordPress Versions, refer to WordPress_Versions.