Do you really need a WordPress security plugin?
My personal opinion? Yes and no. Most of them suck. Most of their features suck.
- They slow down your site.
- They can’t secure/detect everything.
- They cost money.
- They give a false sense of security (BIGGEST OFFENSE).
- (I’ll also cover which features DON’T suck.)
Don’t worry, I’ll explain.
Introduction to WordPress security
To talk about WordPress security, you have to understand what you’re actually securing your site from! Attacks come in various forms and with different motives behind them. And the attacks target different aspects of your site. Without understanding this, you’ll never know how to secure your website. At best, you’ll be a paranoid web-owner installing every random security option without knowing if it has any impact against what you’re trying to secure!
I could make a full-blown WordPress security guide later, but not today!
Common WordPress attacks (and how they work)
Brute-force
- Bot trying rapidly trying different passwords on your login page (usually WP-admin).
- They are a problem even if they can’t get in since their constant effort still overwhelms your server with requests and slow down your website.
- They can also hammer your XML-RPC protocol on WordPress.
Code injection
- Using vulnerability in your website software (usually theme/plugins) or server software (operating system, modules) somewhere to inject code into your site.
- This code can cause unwanted site behavior, typical malware like ads or redirect links to other sites, display prank-style messages.
- The code is also used to open backdoors and access information in your website and database, stealing sensitive content and passwords. Once they have your passwords, they’ll also try it on other sites…like your email, PayPal, and eBay accounts. (Backdoors are basically files that allow the hacker back into your site even if you correct the original vulnerability.)
- The code can also change existing data, such as redirect your links to theirs or changing your PayPal address to their account instead.
- The way these code injections usually get in is from vulnerable code in themes or plugins. This is why it’s important to choose your themes and plugins carefully and to always keep them updated.
DDOS (distributed denial-of-service)
- Using multiple servers to bring your server down by flooding it with massive requests. They don’t steal any info, they just want to make your site go down.
- Commonly used against government, religious sites, or business competitors. Also used for targeting individuals/organizations for other personal reasons.
So there you go! So simple, right? Most website attacks generally boil down to those 3 basic categories. And basically, all the attacks are either to 1) gain entry into your site/server, 2) steal sensitive information, 3) alter the site for their own benefit.
The problem with WordPress security plugins
1. They slow down your site.
This should be public enemy #1. Why?! Because many security attacks are very much a performance issue. Look at the TSA lines at the airports. Super long wait times and they almost never ever catch anyone, right?! That’s what you’re doing to your website. Making it slow as heck for the 99.99% of legitimate users that are never going to hack your site. This is terrible UI by design.
The other problem with a security method that slows down your site is that you’re potentially helping some hackers to attack you better. If their main goal is to overwhelm you with requests and you use a plugin that makes your website slower, and requiring more processing time, well guess…now it’s even easier for them to overwhelm your server with DDOS attack!
2. Security plugins can’t secure/detect everything.
Hear me out for a second. Maybe you think because a plugin can detect 98% of the hacks out there, that means it’s 98% effective…well I say “NO!” Here’s why…most people get hacked because of vulnerable themes and plugins. Security plugins CANNOT secure an insecure plugin. Pretend I kept building new room additions to my house but they had insecure windows and doors…well, I could have a security guard walking around the house but it doesn’t mean those windows and doors are now suddenly locked. So yeah…security plugins can’t prevent most attacks!
The hackers will STILL get into your site. Ok fine, but you have a security guard who will get all the junk files out, right? WRONG! Because they can’t detect all the bad guy. So they’ll clean up maybe 98% of them, but the ones still left will KEEP LETTING THEIR FRIENDS BACK IN!
Ok, fine. So how do we completely clean out a site once it’s been hacked? If you want my honest opinion of having personally cleaned hundreds of sites over the years…you have to do it manually. That’s the only way. If you use any automated tool or security service out there…they catch only a chunk of it but still leave some behind. And then it’s up to you to pray that the small chunk left behind isn’t enough to allow the hacker back in. Sure, some services out there guarantee a 100% clean-up and will go in and manually repair your site. It’s a great deal if they actually honor it but how much money have you lost by now?
Just FYI…here’s a common timeline of how sites get hacked.
- Theme or plugin has a vulnerability.
- Hackers (or their bots) scanning websites eventually find yours and exploits it, creating a hole.
- The site is now vulnerable but the hacker doesn’t get to it until a month later. The hacker’s probably busy with hundreds of vulnerable sites around the world; it’ll be a while before he gets to yours.
- 2 months hacker finally gets in and starts all kinds of crazy things. Messing with the site and information.
- You wake up the next morning and realize something is wrong. You start to fix the damage, usually either by trying a free plugin-scan or asking your “web guy” who will also probably try a free plugin-scan. The problem is your web guy also probably don’t know how he got in. And the access logs that show his traces are already deleted since the system doesn’t save logs past a certain number of hours/days.
- From here you take blind guesses. You’ll update plugins, restore from backups. Then you’ll run a security plugin and try scanning to remove all the hack files. The scans complete.
- From here you basically pray nothing happens.
- A week goes by and then BOOM, you’re hacked again. All the bad files are back and it’s like nothing was ever cleaned. You’re scared as heck. You’ve done everything right and now realize you have no idea how he’s getting in.
- Yes, perhaps the vulnerable theme/plugin was patched but he probably left some backdoors in your site to allow himself back in. Your plugins can’t detect them because they’re written to be somewhat unique and not like the common hack scripts out there in the wild.
- You get desperate, contact a security expert or ask your security plugin to honor their guarantee. The person does a half-assed job mostly, running a typical scan and looking at only the most common folders and files. The mere $100-200 that you paid them doesn’t cover the hours it takes for them to actually scan every little corner of your site.
- You get hacked AGAIN. A 3rd time and again, all the hacks are back! And this time, your security person has the sense to look at the logs and know exactly where the hack is coming from. By now, you’ve been hacked 3 times and lost a time of sleep. Also have pissed off visitors and customers, probably lost a good chunk of revenue as well.
3. Security plugins cost money.
Why does this suck? Well…it’s because it means most of them will be designed and marketing in a way that increases revenue rather than increasing security. Lots of fear-based marketing that prey on ignorant users. And lots of bloated features to justify their cost. The worst part of all is that naive users will stay naive and never learn what it takes to secure their site. They’ll continue to focus on all the wrong things further increasing their trust in all the wrong security measures that don’t actually improve security.
4. Useless feature bloat
This is especially annoying since plugins will try to out-do each other for marketing purposes by loading every possible feature. Even features that are only marginally related to security and really don’t even need to be part of a plugin. Sure, it’s convenient for users but at the same time also confusing and can distract them from the most important security functions.
Common security features (and why they fail)
Let’s go over some common security methods and how they fail against the most common hacks!
- Firewall blocking malicious traffic – they can only block known malicious traffic. Will they be able to block NEW malicious traffic? Probably not if your server is among the first ones to get hit. But sure, the plugin will probably catch it 3-6 months later when the hack is already outdated and “caught”. By then, the hacker’s already got a new script out.
- IP blacklist – do you really think any hacker worth his salt would waste his efforts without using a proxy from a “trusted” IP?
- Malware signature defense – all malware scans are designed to detect PAST malware signatures, not new ones. If a new one is similar enough to an old one, it may be detected. If it’s not, then it won’t!
- Malware scanner – isn’t this funny? Why the heck does it need to scan if it’s already detecting them? Or the scan is to prevent you from inadvertently putting hack files on your site/server? Again, the malware scanner doesn’t detect everything and not only that but it slows down your server when it runs. How annoying.
- Brute force protection – limiting login attempts. This one’s good!
- Enforcing strong passwords – this is silly. You don’t need a plugin for this! Just use strong passwords.
- Hiding WP-admin login page – this works somewhat in that hackers can’t find your login page to attack it. But it also fails (slowing down your site/server) if the automated bot keeps trying to reach your login page and your 404 page isn’t cached.
- Checking WP core files – this is a nice feature; making sure your WordPress core files aren’t compromised. It’s nice but at the same time, believe me…it’s obvious when you’re hacked and the moment you realize one is affected, you’ll already know to immediately replace all WP core files. Everybody who’s been hacked knows immediately to check wp-config.php, index.php, functions.php. I can’t think of any hack that doesn’t prioritize these files first!
- Hack reports – it’s nice because you see how many hacks are thwarted and makes you more aware of how often your site is being hit by bots and hackers. But also over-estimates the plugin’s effectiveness since many of these hackers would have been thwarted by WordPress naturally!
- Bullshit features – captcha against bots/spammers, logging user actions, forcing SSL, blocking file editing, blocking XML-RPC protocol, removing WordPress site information from the code, changing database prefix. All this junk isn’t specifically-related to WordPress security and doesn’t actually thwart any attacks. They also don’t need a security plugin to implement. They’re a bunch of bloated features to justify the cost of having a security plugin.
Fine, so what’s the best way to secure WordPress?
- BACK UP YOUR SITE. So that things can be repaired!
- Update your WordPress core, themes, and plugins.
- Use only quality themes/plugins. Avoid outdated ones or ones by smaller little-known development teams. Don’t buy themes/plugins illegally or download from unknown sources. Also avoid keeping any unused themes/plugins since they create unnecessary directories for hacks to hide inside and making your job harder when you have to find the hacks.
- Use strong passwords. And don’t use the same passwords for your site that you do for email and your PayPal account.
- Protect against brute force.
- Have some kind of brute force protection on your login page. Block XML-RPC protocol if you don’t use it.
- If you’re paranoid, you can install a security plugin that has a malware scanner BUT leave it deactivated. Don’t have it running constantly. And every now and then or when you notice issues with your site, you can run the scanner to see what it finds.
- Have a contact for a good server-admin or programmer for when you do get hacked. It will happen eventually and you’ll need someone you can call immediately. Are you really gonna trust your business site to random plugin? It’s much better to trust a live human-being who knows your site and can be made to guarantee their work.
- All other common sense applies. Use updated webhost, web-server, PHP, etc.
- You can install Cloudflare or Sucuri for extra security at the DNS level. Problem is they only help against DDOS attacks which most of you will never get! DDOS attacks are kind of expensive and usually targeted for very specific purposes.
So does this mean you NEVER use security plugins?
Yeaup, I don’t use ANY security plugins on my site. Again, the reason why these security plugins suck is because:
- They can’t secure vulnerable themes/plugins. Most of you getting hacked are due to vulnerable code in your themes and plugins. Your best protection against this is not a security plugin but simply to keep your WordPress core, themes, and plugins updated!
- They can’t detect the newest hacks and attacks. Their system is designed against detecting old ones that are already known and probably not circulating anymore. Don’t be fooled by “this scanner detects 5,000,000 known signatures”…it’s bullshit. Almost all of them are not used anymore. Hackers are always coming up with new hacks to exploit new vulnerabilities! So don’t waste your time with scanners slowing down the server and still not detecting the latest attacks. ARGH, I’m so impatient explaining all this!
- They slow down your site. How annoying, right? They can’t detect the latest stuff AND they slow down your site? What’s the point anyway?!
- NOTE: if you get hacked, you’re welcome to run a security plugin just to help repair/remove the most obvious hacked files but you still need to hire a professional to make sure the site is completely secured!
More interesting reads:
- TheXC3LL shows how to defeat WordPress security plugins
I’ll get some more helpful examples soon. Honestly, I think security plugins do almost nothing but slow down your site and give you a checklist of basic “security tips”. I see tons of people still getting hacked with security plugins installed and the ones that don’t get hacked are probably because their site wasn’t vulnerable in the first place.
So… how do we protect against brute force (“have some kind of brute force protection on your login page.”) as you said, without a plugin?
Also, how can we match the security of, say, WP-Engine, with a combination of RunCloud/GridPane+Linode/Vultr as you suggest? Would you recommend to go with Vultr over Linode simply because of their DDoS protection feature?
Thanks mate,
Your work is enlightening.
WP Engine is generally not in any way more secure than anybody else. Their hardware is not any more secure. Your WordPress app at WPE would still be the same as anywhere else. I like Linode over VULTR. I haven’t heard much good out of VULTR’s supposed DDOS protection; there are many complaints about customers getting null-routed anyway. If you want real DDOS protection, I would suggest Cloudflare’s paid plans or another DNS proxy security service. I also don’t think you should worry about DDOS protection unless if you know for sure that your site/service/server attracts it. Those kinds of attacks are usually targeted and not random IMO.
ps would you currently recommend GridPane or RunCloud?
Really tough call. Depends on what you’re looking for. If you want a really mature environment that works and very developer-friendly, RunCloud is the pick. If you want something more simple and clean, and more “supportive” I think GridPane is better. GridPane was a little faster for me as well. My best advice is to get try their free plans or trial and pick the one with the UI you like more. Workflow is the difference for me between these two rather than performance. If all you got is 1 site and nothing else, GridPane seems like the better pick.
I also remembered to finish this guide thanks to your question: GridPane vs RunCloud Managed Hosting Panel Review
That’s simply not true.
And you could state the same arguments for almost any plugins.
Problem is, most of your readers don’t have your technical knowledge and capacity or access to a server (VPS or private) as you do.
Most are hosting their sites on shared accounts.
Of course you can implement by yourself any code found in any plugin, but most of time you simply aren’t able.
That’s why plugins exist.
In addition, as collateral, I find this recent “speed” fever pathetic.
It has been inoculated by Google that simply needs its ads to run faster and everybody jumped in the wagon posting speed related topics everywhere like crazy.
Of course it’s better to have your site load in 2 secs rather 20 and, sure, every line of code you add to a website you’ll lose some nanoseconds.
So what? The question is: what is more important in each and every step you take, the functionality you gain or the speed you supposedly decrease?
And, anyhow, speed measurements are, most of the time, limited to homepages and say nothing about further navigation – something much more important than the initial load of the homepage! Furthermore, the whole “speed” fever is essentially relevant to online shops and is of far lesser importance for other types of sites.
Like your own for instance: your site loads super-fast. Great! Would it make any difference if it was loading 3,4,5 times slower? Certainly not!
But this speed you get has a price: you have very few utilities running. Just a blog with pure text and images.
Let’s take this comment section for instance. It’s extremely basic. Visitors are just able to post comments. Done.
But it’s really a pity there is no follow-up as we aren’t able to subscribe to comments and be notified when you or another visitor reply to them.
You may code this by yourself or use a plugin for that and you’ll certainly lose some nanoseconds for doing so for sure. But what is more important in such cases: the functionality or the speed?
Always a pleasure reading your posts but I don’t always agree with you.
Cheers!
Hey John,
Good to see you again! I think your comment is debating more of the over-obsession with speed rather than whether or not security plugins actually help. Just curious which features you think are absolutely needed and only available via security plugin?
Because speed is all about your post. What else?
In summary, you say that anything useful those plugins do can be done manually.
I know where you want to head to: one of my best friends is coder and developer and we had this debate since we were teens.
He likes executing everything from the command prompt on his computer running Linux and I never understood how this thing works.
I’ve always been using Windows and I like having graphical windows and checkboxes for everything.
Same goes with security plugins.
I know I can run many of their features with snippets or at htaccess level but I’m really happy having a graphical interface with checkboxes and guidance.
I use iThemes and glad to have those features (I don’t use Cloudflare):
– blacklist threshold, blacklist lookback periods and lockout periods for invalid logins and 404 (brute force protection)
– white/blacklists
– notifications of main events
– custom login page
– banned IPs and HackRepair.com’s blacklist feature
– immediate ban of users trying to login with “admin”
– disabling XML-RPC – XML-RPC, restricting access to most REST API data, blocking XML-RPC requests that contain multiple login attempts
I mainly agree at one point with you: the best security protection are regular, tested and off-site backups.
And also that the main security risks come from outdates plugins – and also phishing emails!.
John, I secretly think you’re not even reading my guide. Speed was only one of the issues I mentioned in the plugin.
No secrets 😉
My second reply is not about speed.
You post starts like that:
They slow down your site.
They can’t secure/detect everything.
They cost money.
They give a false sense of security (BIGGEST OFFENSE).
I initially replied to the first point because I’m fed up with speed obsessions.
The second point is half true: not everything (nobody can) but many.
The third is false – I use iThemes free.
I finally replied to your last point with my second message.
I hope these my notes add some clarifications:
1. They slow down the site. This matters to me. Plain and simple. It’s not an obsession. 200ms difference in desktop time can be 500ms different in mobile time or more. When designing ultra-professional sites, whether a blog or ecommerce…I want it to load super fast like those ultra-polished million dollar sites. If this isn’t important to you, then by all means…use a security plugin.
2. I already explained this point and I think it’s a matter of personal experience. I’ve seen so many sites WITH security plugins installed that still got hacked so awfully. I’m absolutely convinced they are a waste of time against serious hacks and recent vulnerabilities. Are they still effective for old already-discovered injections and hacks? Absolutely, but practically useless against day-zero attacks with any due diligence behind them.
3. Their best features cost money. Their free features, many of them can be implemented for free.
Ultimately, I share only my personal opinion here for those who don’t have one or simply curious to know how I feel. But if your past experience shows otherwise and you love how they work then by my all means don’t rock the boat.
Master Johnny,
I moved a big site to GridPane – together with SWIFT (free) and Shortpixel I improved my Pagespeed to 91 from 82. Nice! And that was a Managed WP host that cost 20 times what I pay now. I’ll try to get it to a 100 🙂 Anyway, since GridPane is Nginx (the code snippets you gave are for htaccess file), I want to take some security measures:
How do I implement protect against brute force and my login page?
How do I block XML-RPC ?
How do I Disable Directory Indexing and Browsing?
Thanks!
That’s the unfortunate thing with NGINX, unless you have access to and are able to add server configurations, there isn’t a way to do it. you’ll have to use a plugin which adds extra PHP load on every page request but hey, it’s not so bad. Either way, happy for all your improvements, man!
Nginx+Plugins > Apache + Htaccess commands, speed-wise? 😉
What if I just add, for instance, “add_filter( ‘xmlrpc_enabled’, ‘__return_false’ );” to a plugin file? And other similar snippets to perform the other functions.
And if going the plugin route, should I install a few separate ones (Login Lockdown, Disable XML-RPC, etc) or All In One WP Security and Firewall?
I think if you have to ask that question, it’s better you use one of those complete plugins that do everything.
It depends on how things were configured and set up but generally, pure NGINX is gonna be better than Apache.
Johhny, can the WPFail2Ban plugin solve both problem – protect against brute force login and XML-RPC attempts ?
From what I see, that plugin is not a security plugin…it simply LOGS all the incoming login attempts that are recorded by Fail2ban (which is a module installed directly from the server and not a PHP plugin installed from WordPress).
I’m suggesting this because GridPane replied to my mail:
“On free plans the configs already come with the following:
rate limiting on wp-login:
This limits to one login per second, but for brute force attacks we recommend something like a login limit plugin in addition, or something like wpfail2ban which integrates login attempts with the server fail2ban firewall. (Prometheus on paid plans comes with this via an autoconfiguration)
location = /wp-login.php {
…
limit_req zone=one burst=1 nodelay;
…
}
XMLRPC endpoing is already blocked with a deny all:
location = /xmlrpc.php {
deny all;
}
You have to stop the pingback header, you can do that at the nginx level with a:
fastcgi_hide_header X-Pingback;
Or you can use plugin based solutions. Its necessary to remove the pingback because if you block the xmlrpc endpoint but leave the pingback header then you are open to another vulnerabilty … being flooded with pingbacks.”
…
I’m on the lookout for a lean plugin that can solve both vulnerabilities, thought WPFail2Ban would be the one 🙂
I think if you already have GridPane, simply ask their support for which plugins would work best with their stack and go from there. They’re great guys with lots of knowledge. Try and see.
I did! Update:
“I am afraid I don’t know which plugins would best suit this purpose, since we strongly believe this sort of thing should be sorted out at a server level and that is why we do that. Over the next month the 50 or so gpcli features and about 200 commands will be rolled into the UI for sites built on the new stack, and a new stack server customizer. Free plans will get access to the new stack, but not any of these features though… free plan will be limited to basic functionality, enough to build fast secure sites with SSL, but nothing else… the aim is to reduce the support burden of free to as little as possible. For these features in our paid stack… they are all currently in gp-cli, and they will all be integrated into the site customizer. There will be a toggle for XMLRPC disable, there will be a input for managing rate limiting on wp-admin and wp-login, there will be toggles for wpfail2ban – user enumration, comments, spam, login attempts etc, toggle to disable concatenation vulnerability, toggle to disable emoji, etc etc”
Nice!
Hi,
I read your advice and find it very useful.
A question:
I was impressed that you don’t use spam filters for your comments, can I ask you how it is possible?
I have a mixed comment spam solution across all my sites. Some on Akismet, others on Antispam-Bee or some honeypot alternative. I’m scared to try automated solutions as they always get a few false positives. And it’s tough for tech sites because we share links a lot. With this site, I use only Akismet and nearly all spam is successfully caught in the spam box which I manually clear out from time to time.
Thank you for this detailed and informative post. It makes a lot of sense to me which is really saying something since I am not a developer, barely beyond a newbie to all of this. But last week I found my site was nearly in operable because the CPUs were being maxed out at SiteGround. I thought it was because I had added so much blog content. I did not know I needed to stop attacks at the server level instead of using PHP/ .htaccess/ All in One Security plugin. But because the site was so crazy slow I assumed I must have gotten hacked. I whitelisted my IP address. Then found a couple online scanners which both said the site was clean. Over the course of a couple of days I set things up to go through Cloudflare and used DNSSEC to secure my domain.
I have two questions for you, if you have time:
1. Are you saying firewall rules are a waste of time? I found a lovely set online which I was planning to add to my Cloudflare account:
Original poster/commenter said “You can use my Cloudflare rules below:
https://blog.situstarget.com/wp-content/uploads/2020/01/Firewall-Rules-for-WordPress.txt
First, rule is to protect WordPress from injection.
Second, rule is to protect WordPress from Bad Spider
Third, rule is to protect WordPress from backdoor
Fourth, rule is to make Cloudflare as your VPN to login WP-admin & WP-Login.php.”
[This was included in comments at https://blog.runcloud.io/cloudflare-firewall-rules/ ]
2. Do you have a list of preferred Cloudflare settings for your clients? Or only what’s listed in this post?
Thanks again for sharing your knowledge. I very much appreciate your generosity.
Hi Morgan,
You can definitely start with those rules. If you don’t know what you’re doing…try everything and see if you’re website is hindered in any way. If you can’t tell, you’re fine. 🙂
Wow Johnny thanks for the fast response! And I was delighted to stumble across this post
https://wpjohnny.com/cloudflare-settings-guide-best-performance/
May your tribe increase! 😊
Great article Johnny. One thing I’m curious about, though, is your suggestion that enforcing strong passwords isn’t necessary. Is that because you think only admin-level accounts are a real security risk?
Obviously membership, learning or e-commerce sites are going to potentially have a lot of users, but at subscriber or author level. A large organisation may have a number of editor accounts though. Could hacking one of those be a security risk?
I’m not against strong passwords, I’m against running a plugin to enforce it. Hahaha.
I get that. But my question was about situations where manually enforcing it is onerous to the point of being impossible. Are weak passwords for editor accounts a security risk?
There are so many “depends” in this situation…
– If you have brute-force protection, even a weak password is easily defended since they wouldn’t get enough tries.
– Weak passwords lacking difficult characters are better than weak passwords that are short.
– If editor accounts only edit content and nothing else and you have regular backups, it doesn’t seem so bad.
I could go on and on. It’s up to you to take the risk or not. Regardless whether I say it’s ok, you have to weigh the hassle of password security against the hassle of damage repair should any hacker get in. Besides, there’s a dozen other ways hackers can STILL get in.
Static Sites are vastly more secure and faster than WP or other CMS platforms. Plus you can code any way you want it! I have an static site + static blog and don’t bother with static site generators, more code bloat I don’t need. For even more security skip frameworks also; if they get hacked, it now becomes your problem to — misery loves company…
What do you think about this list?
Restrict access to files and directories
Configure security keys
Block directory browsing(can be reverted)
Forbid execution of PHP scripts in the wp-includes directory(can be reverted)
Forbid execution of PHP scripts in the wp-content/uploads directory(can be reverted)
Block unauthorized access to wp-config.php(can be reverted)
Disable scripts concatenation for WordPress admin panel(can be reverted)
Turn off pingbacks(can be reverted)
Disable unused scripting languages
Disable PHP execution in cache directories(can be reverted)
Disable file editing in WordPress Dashboard(can be reverted)
Change default database table prefix
Enable bot protection(can be reverted)
Block access to sensitive files(can be reverted)
Block access to potentially sensitive files(can be reverted)
Block access to .htaccess and .htpasswd(can be reverted)
Block author scans(can be reverted)
Change default administrator’s username
Seems fine. You still gotta update themes/plugins. That’ll make the biggest effect.
Actually, I am using the Wordfence Login Security plugin with two-factor authentication, and it disables XML-RPC. And as you said, strong password, regular backup… never had a problem since, and it doesn’t seem to slow down the site as well.
I tend to agree with you, overdoing security is not really worth it, generally, especially for small websites.