This post is a response to Yoast at https://yoast.com/wordpress-security/.
Yoast is a SEO company in the WordPress ecosystem since 10 years now. They are professionals without any doubts, but for SEO purposes, not for Security.
After my read on that particular and recent post from them, I had to answer and fix the issues. Some of those points are good, but some are so bad that could lead to a hacked website, for real.
Giving security tips without knowing why you have to do it is one of the worst idea ever. The bad points are on the Internets for way too long, but with a chance, Google won’t bring those old post back right?
False because of this new Yoast post, sorry :/
1. Don’t use ‘admin’ as a username
Yoast says “If you’re working with an older site that already has an ‘admin’ user, it might be time to delete that account and transfer any content or access to a more secure username!”.
Ok so let’s say I’m running a website, like a e-commerce one, or any website where anyone can subscribe and become a simple member.
If I listen the Yoast’s tip, I have to delete the “admin” account. So what’s next?
Anyone can (re)create the “admin” account? And set the password on “123“? Just for fun?
Wow, this is not secure at all. Any login attempt from a basic hacker script will result as a positive login.
The real thing is, never delete the “admin” account if your subscriptions are open, instead, downgrade its role to “Nothing on this website“.
If you don’t run an open subscription website, you can delete it, ok.
Demo from 2011 with IFTTT
— Julio Potier Ⓦ (@JulioPotier) March 23, 2011
The image is not available anymore (2011) but the filename speaks for itself. I’ve created the “admin” account on ifttt.com because they didn’t protect it, they contacted me to rename it. You can also forbid the creation of this username.
Thanks to SecuPress, it will secure your “admin” account and can block many usernames natively.
2. Use a complex password
Complexity if for human brains. For a computer or a script, a character is still a character. If you think that “*” or “!” is more secure than “a” or “b”, don’t fool yourself, this is a mind trick.
A good password is a long one.
3. Add two-factor authentication
Of course, a 2FA is way more recommended than a “good password”. In SecuPress we use a PasswordLess 2FA so you’ll get an email when you want to log in, using only your username, password is dead!
4. Employ least privileged principles
Good point again, and this could have been used for the “admin” role instead of deleting it. Just saying.
5. Hide wp-config.php and .htaccess
The post says:
“For better WordPress security, you will need to add this to your .htaccess file to protect wp-config.php:”
Ok, but, which better security, which protection does that add to my website, to my file?
This is (again) not explained. Why? Because they just don’t know why.
Also, this does not hide anything, and even if it was, hiding things is not securing them…
So. Let’s see the code now.
[pastacode lang=”apacheconf” manual=”%3CFiles%20wp-config.php%3E%0Aorder%20allow%2Cdeny%20%0Adeny%20from%20all%0A%3C%2FFiles%3E” message=”” highlight=”” provider=”manual”/]
Without this code, what happens when you load your own
wp-config.php file on your website? Blank page.
Why? Because this is a PHP page, with nothing to print. You can’t read its content just by accessing it by its URL, never.
What does that code add? It will return a 403 HTTP error code instead of a 200 HTTP ok code. What’s the difference for us? Nothing. In both cases, you can’t access the content of the file.
This is not hidden, this is not more secure.
Maybe you’ll think about possible vulnerabilities that could target this file and read it, right? Like the old Revolution Slider flaw from august 2014 where a simple URL parameter could read out config file.
Well, this doesn’t protect from that kind of exploit because this protection is on Apache (server) side and exploits like this one are made on WordPress side. PHP will always have access to this file (or your WordPress is dead.)
TL ; DR: You don’t have to protect those files with this because it doesn’t add any layer of security, just a mind trick again.
6. Use WordPress security keys for authentication
You know what? You can delete them, WordPress will create new ones in the database with the same security. Mind trick!
If you fear to let your keys in this file, delete them. If you fear to have the keys in your DB in case of SQL Injection, keep them. If you fear both, install SecuPress, it will create a special file with autogenerated keys that can’t be humanly read. You’re welcome.
7. Disable file editing
Of course you have to ! Using HTTP to edit file is a NOGO for me. FTP (sftp, ftps) or SSH is the way to access files, not HTTP !
HT(TP) means “HyperText” and F(TP) means “File”, enough said.
8. Hide your login and limit login attempts
Yes but remember that a human can still find it sometimes. If you’re running an open sub area, the new URL will be known and potentially leading to exploits.
So remember that here, we’re protecting the login area only from the bad bots, zombies and auto-scripts out there, not from humans.
Limiting the login attempts is, for me, a mandatory feature BUT don’t rely on IP, it can be spoofed leading to an infinite attempts possibilities. Remember the Wordfence 5.2.5 security patch? We do.
Instead, rely on the existing user account and use its meta data to track the tries. SecuPress does it like that and works like a charm.
9. Be selective with XML-RPC
Well, yes, but if you don’t know what it is, I’m 99% sure you can disable it. XMLRPC came in 2005, 10 years later REST API was introduce into WordPress, so, it’s been 5 years now, yes, you can disable it.
If you don’t now how, SecuPress can do it for you, 1 checkbox. Job done.
10. Hosting & WordPress security
Of course a host is important, they are the most forgotten “security feature”! My best one is o2switch.fr (french only), they are very pro and best support ever (way to much my fault…).
11. Stay up to date
Yes, do it now.
12. Put more security layers in place
Post says “It’s also worth considering that many Content Delivery Systems now include firewall functionality“. Yes, but don’t rely only on Cloudflare to protect a Website, this is not the same layer, this is why you need a WordPress Security Plugin AND a CDS like Cloudflare or a WAF like the one from Sucuri.
13. The best security plugins & themes
Post says “We recommend being mindful of testing different themes or plugins, especially if you’re not using a test server.” I had a dream. Where everyone could check the code of all the plugins and themes they are using, but hey, not everyone can/could do that. If you can afford it, do it. Else, check the community, videos, blog posts about a particular product before using it for real.
14. Don’t forget logs & monitoring
Logs do not secure anything, but they are important in order to easily keep an eye on what is happening on our sites.
If you need to audit a theme, a plugin, ask us. If you need to learn more about WordPress Security, you can follow a training like our LearnWPSecurity.com (french only).