Yesterday, August 18, 2020, the Wordfence Live team covered 10 WordPress Security Mistakes You Might be Making. This companion blog post reviews the recommendations we provided to avoid these mistakes and better secure your WordPress environment.
You can watch the video of Wordfence Live below.
You can click on these timestamps to jump around in the video.
- 11:24 #10:Changing the WordPress login URL.
- 16:00 #9: Not using SSL/TLS certificates on your WordPress site.
- 19:00 #8: Using “admin” as your WordPress administrative username.
- 22:30 #7: Using weak passwords.
- 24:05 #6: Not using a Web Application Firewall like Wordfence.
- 41:18 #5: Insecure hosting choices.
- 44:50 #4: Poor user access management.
- 48:13 #3: Using nulled plugins or themes.
- 49:54 #2: Reusing passwords in multiple locations.
- 51:28 Mistake #1: Not updating WordPress plugins, themes or WordPress core.
Mistake Number #10: Changing the WordPress login URL.
Some WordPress users request that Wordfence add the ability to change a site’s login URL. For example, instead of logging into WordPress at wp-login.php, a site owner can use methods of changing the login URL to something completely different. There is a reason we haven’t implemented the feature in Wordfence and why we don’t recommend hiding a site’s login as a security measure. Hiding the login URL is security through obscurity, which often leads to a false sense of security.
WordPress login URLs can easily be detected and bypassed by most attackers. Therefore, it’s not the best technique to limit login attempts and potential attacks. A site owner with a renamed login URL feels their site’s login is adequately protected, but is missing several very important security control mechanisms.
Instead of changing your sites login URL, we recommend:
- Enabling brute force protections. This includes locking out excessive login requests. Brute force protection is available in both the free and premium versions of Wordfence by going to Firewall Options > Brute Force Protection. .
- Using strong passwords. This will help prevent brute-force and password guessing attacks from being successful. Please see the section “Using weak passwords” for our recommendations on creating strong passwords.
- Adding .htpasswd protection to your wp-admin area. On a web server, .htpasswd uses flat-files to store usernames and passwords for basic authentication of HTTP users. These protections are outside of your WordPress PHP/MySQL configurations and secure access to the files that your administrative dashboard uses for managing your site. Please know that when you do this, you may need to whitelist admin-ajax.php in the .htaccess file if your site uses any front-end AJAX requests.
- Using two-factor authentication. This adds a second layer of protection to your login form. If an attacker is able to successfully get access to a compromised password, they will be unsuccessful at logging in due to the second layer of authentication. Two-factor authentication is available in both free and premium versions of Wordfence. You can find this by going to the Login Security section of your Wordfence dashboard. .
By taking these steps to improve your site’s login security, you’re addressing real attack vectors with solid protections.
Mistake Number #9: Not using SSL/TLS certificates on your WordPress site.
SSL/TLS certificates are often misunderstood and frequently a missed step in securing WordPress sites. However, they are vital to protect the confidentiality of the data in transit from your site visitors’ browsers to your webserver. They also have an impact on your site’s search rankings as Google favors sites using SSL.
What is an SSL certificate?
SSL/TLS certificates encrypt the traffic between clients and servers and securely send data over HTTPS. An SSL/TLS certificate essentially makes it possible to convert all of the traffic being sent over the internet between a client and your server into a non readable form by encrypting, or “jumbling” up, the data with the use of a key. Only the webserver has a key to decrypt or “de-jumble” that data and respond to the requests again with the data encrypted, or “jumbled,” in the response.
One simple example of why you need an SSL/TLS certificate is that WordPress sends credentials in plaintext. This is what an attacker sniffing a network can see if there is no SSL/TLS certificate installed on a site when someone logs on to a WordPress site:
With this data exposed, an attacker can take the host information, username, and password and then gain access to your WordPress site. Worse yet, sites that take payments may send payment information in plain text, a human readable format, due to the lack of an SSL/TLS certificate, making it possible for attackers to steal that information in transit. Your site users’ data can be significantly impacted if you are not using an SSL/TLS certificate, and that is why search engines favor sites with these important security measures in place.
Here is an example of what an attacker sniffing a network can see if there is a SSL certificate installed on a site when someone logs on to a WordPress site:
It’s clearly unreadable and impossible to decipher exactly what is going on in the requests.
Several hosting providers offer one click solutions that will deploy a free SSL/TLS certificate to your site. Let’s Encrypt is a nonprofit with a mission to create a more secure and privacy-respecting Web by promoting the widespread adoption of HTTPS. They offer free and easy to use SSL certificates so that every website can easily deploy HTTPS.
Mistake Number #8: Using “admin” as your WordPress administrative username.
Another common mistake that we see quite often is WordPress site owners still using the default ‘admin’ username for their primary administrative user account. This can have a negative impact on your site due to bots attempting to brute force a password for the ‘admin’ user or exploit vulnerabilities using ‘admin’ as the default username in their scripts.
We have seen some vulnerabilities in the past that have relied on WordPress site’s having the default user account username set to ‘admin,’ like the privilege escalation vulnerability discovered by WebARX in the ‘ThemeGrill Demo Importer’ plugin. Having a username other than the default ‘admin’ would have kept users safe from the privilege escalation portion of this vulnerability, thus making the exploit less attractive to attackers and reducing the impact if your site were to be compromised.
There are two ways you can correct this. The first way is to create a new administrative user account with a new username and delete the old ‘admin’ account. The username can be something complex or something relatively simple but unique. The more complex, the harder it may be for attackers to discover the username. If using this method to change the default username, you must make sure to attribute all content created to the new user when you are deleting the old admin account.
The second way you can change your username is by going directly to your database using phpMyAdmin from your hosting account, or similar database management tool, and updating the username in the *_users table. This is the simplest way to change your default administrative username, and what we recommend.
Regardless of which method you decide, as with any change, we recommend taking a backup beforehand so that if anything goes wrong during the process you can quickly restore the site.
Once you’ve changed your username to a stronger username, navigate to the Wordfence Firewall and find the setting to ‘Immediately block the IP of users who try to sign in as these usernames’ and paste ‘admin’ into that field. This will provide another layer of login protection and automatically block any bots trying to attack your site using the default ‘admin’ username.
Mistake Number #7: Using weak passwords.
This is one of the most common mistakes across the web, and we are not just talking about WordPress sites. Strong passwords are the front-line defense against brute-force attacks and compromised user accounts, thus it is one of the most important things to take into consideration when making sure your site is secure.
Passwords like ‘password1234,’ ‘qwerty,’ ‘mydogsname,’ are all too common and way too simple. It takes just seconds to brute force or manually guess weak passwords, thus only taking attackers seconds to get into your account.
We highly recommend taking the following measure to stop using weak passwords:
- Create Strong Complex Passwords. Your passwords should consist of more than 10 characters, with at least one number, one symbol, and one uppercase character. The more diverse and complex the password is, the longer it would take an attacker to guess your password and gain access into your account or WordPress site.
- Use a Password Manager. This will help you store the complex passwords for all of your various sites so you are not reusing passwords across sites. One compromised password used on one site can lead to several other site accounts being compromised if you are using the same password regardless of its complexities.
- Check your password on haveibeenpwnd.com. Have I been pwned is a great resource to monitor online accounts that have known compromised passwords. In the event a password gets compromised for an account, you should change it immediately.
Mistake Number #6: Not using a Web Application Firewall like Wordfence.
Web application firewalls are vital for open-source projects like WordPress that have thousands of people contributing to the themes and plugins on the world’s most popular content management system.
What is a Web Application Firewall (WAF)?
A WAF acts as a gateway, checking requests from users to determine what is allowed and what is not allowed. Whenever a request is deemed “allowed,” like a legitimate user is logging on a site, the firewall will allow the request to go through. When a request is deemed “not allowed” due to a firewall rule, then the WAF will block that request.
What is a firewall rule?
A firewall rule is an instruction that tells the firewall when to accept or reject a request. A very basic firewall rule in the format of a statement would look like this:
If the request body contains <script> then block due to potential cross-site scripting attack.
Why is it important?
WAF’s block malicious attacks, like an attacker attempting to exploit a vulnerable plugin, and ultimately protect your site from getting compromised. Vulnerabilities are constantly discovered in WordPress themes and plugins, and WordPress, powering over 35% of the internet, is constantly under attack. Not having a firewall is like leaving your front-door unlocked with a sign in your backyard saying the front-door is unlocked in a neighborhood with roving attackers looking for their next victim.
You can harden and patch, but if a zero-day vulnerability is discovered and actively exploited before a developer has a chance to patch, then a WAF may be your only hope until a patch has been released.
Wordfence’s built-in Web Application Firewall.
The Wordfence plugin’s built in Web Application Firewall has a generic list of firewall rules that provide blanket coverage for the most targeted vulnerabilities like Cross-Site Scripting, Arbitrary File Uploads, SQL injection, Directory Traversal, and more. This means our web application firewall provides a very extensive coverage baseline. Our Threat Intelligence team then enhances that coverage by creating custom firewall rules for plugin, theme, and core vulnerabilities for specific coverage of vulnerabilities that will likely be attacked.
Mistake Number #5: Insecure hosting choices.
Poor hosting choices can have detrimental security consequences on your WordPress site. You want to make sure your hosting provider offers all the functionality you need to ensure that your WordPress site is secure, and that you are making the right choices when it comes to how you host your sites.
When setting up hosting, look for the following.
- Will your account be properly isolated? Make sure your site will be properly isolated if running in a shared hosting environment. This includes making sure not to run multiple sites on the same hosting account, and making sure you remove old sites that are not in use. Make sure that, if another site hosted on the same server gets compromised, it won’t affect your site. It doesn’t matter how secure you make your main site if an older, insecure version of your site in a subfolder gets hacked.
- Does the host provide access logging? Logs will help you determine when and if an intrusion has occurred. This helps you determine what happened so you can prevent it from happening again.
- Do they allow you to install an SSL/TLS certificate for free? Most solid hosting providers let you know that security is a priority by offering this for free from providers like Let’s Encrypt.
- Do you have a dedicated IP address? Sharing IP addresses can lead to your site getting blacklisted if another site hosted on the same IP address is hacked and gets blacklisted. This could affect your site’s reputation just by being in the wrong neighborhood.
- Do they offer SSH/SFTP/FTPS? Just like with SSL/TLS certificates, SSH, FTPS and SFTP offer a means of transferring data over an encrypted channel so that data can’t be easily intercepted. You want to make sure your hosting provider offers this option instead of plain text FTP so that file transfer data can’t be easily read by an attacker on your network.
Mistake Number #4: Poor user access management.
User access management is often overlooked by WordPress site owners. User registrations and the default roles assigned to those users can lead to compromise when done haphazardly.
We recommend considering the following practices.
- Grant users minimal access. Follow the principle of least privilege by granting users the minimum amount of privileges they need to on your site. For most standard sites this will be “Subscriber” and for most WooCommerce sites this will be “Customer.” You can set this value by going to the user management area of wp-admin
- Disable user registration unless it is required. If your site has no areas that require user registration, then disable this feature. Several WordPress vulnerabilities discovered in the past have required some level of user permissions. By disabling user registration, you eliminate some risks of several vulnerabilities.
- Enforce strong passwords. With your administrative accounts using strong passwords, ensure that your users are also using strong passwords. As these accounts can also become a target for attackers, make sure they are optimally secured. You can do this with Wordfence by going to the Wordfence Brute Force Protection section and enabling the option to “Enforce Strong Passwords.”
- Require 2-factor authentication for administrators and publishers. This can be enabled in the Wordfence Login Security section.
Mistake Number #3: Using nulled themes or plugins.
Nulled themes and plugins are premium themes and plugins that are offered for free on “nulled” offering sites. These sites often look illegitimate and offer premium plugins and themes as “free,” “nulled” or “unlocked.”
These nulled themes and plugins almost universally contain malicious code that will infect your site, and any other sites hosted in the same account, as soon as they are installed. One recent example of an infection campaign stemming from nulled theme and plugin use was wp-vcd.
It can often be hard to determine the root cause of this type of infection as most people aren’t aware that they actually infected their own site with malware by installing one of these nulled themes or plugins. Always source your plugins and themes from the original developers, a reputable marketplace, or the wordpress.org directory.
Mistake Number #2: Reusing passwords.
A common, yet simple mistake WordPress users often make is reusing passwords across accounts. When our Security Services Team cleans infected sites, they often find sites using the same password for their hosting account, WordPress website, and FTP account. Of course, if one account gets compromised, all the accounts get compromised.
Even beyond your WordPress installation, we recommend using unique passwords for every account you use. Using the same password on another site that is then compromised as well as your WordPress site can be detrimental. Our Security Services Team has performed a number of high profile incident response investigations that determined passwords used on other sites, as well as the WordPress site or even on WordPress.com-connected sites using Jetpack, led to extensive intrusion with admin accounts being compromised.
Our simple recommendation for this is just to not reuse passwords. We highly recommend using a password manager such as 1Password or LastPass to store long complex passwords that will help make sure that all of your digital assets, from your WordPress site to your accounts with financial institutions are protected.
Wordfence also has an option to prevent the usage of passwords found in data breaches, This option applies to administrators by default, but can be set to include all users that can publish blog posts.
Mistake Number #1: Not updating core, themes, plugins.
The majority of hacked sites cleaned by our Security Services Team were compromised due to vulnerable plugins, themes, or even outdated core WordPress installations. All of these intrusions could have been prevented by practicing good habits in maintaining your WordPress installation.
To stop making this mistake, we recommend updating your plugins, themes, and core as soon as a security patch is released. Use a management or maintenance tool like Wordfence Central if you have numerous WordPress sites to manage. Wordfence Central is completely free, and it allows you to set up alerts for security events, including when the Wordfence Scanner detects outdated and vulnerable plugins. Wordfence Central links to each site’s wp-admin so that you can easily update your themes and plugins, and allows you to view which sites require action based on their scan results, making performing WordPress updates easier and faster.
We’re all human and mistakes happen. Sometimes important security decisions are simply overlooked or forgotten about, so it’s always a good idea to revisit your WordPress site and check on its current security posture.
We hope that providing you with these 10 WordPress security mistakes will encourage you to check on your site and make sure you are following the best practices associated with a secure WordPress environment. If you are not, we have provided you with some of our recommendations to help fix those security mistakes.
If you have any friends and colleagues using WordPress, share this post with them. The safer we make the entire WordPress community, the safer we all are from attackers looking to compromise WordPress sites.
Want more? Check out these three additional mistakes that you might be making not already covered by this post.