7 Popular WordPress Security Myths
Because of its incredible popularity as a platform, WordPress enjoys a sizable, generous community of users that spend their time sharing information, resources, tips and insights with other WordPress users online. Understandably, online security is at the forefront of concerns for many site owners, and a lot of the online conversation about WordPress centers around the best ways to keep your site safe from hackers and security breaches. Despite the best of intentions from most users, there are a few myths surrounding WordPress security that persist and spread like wildfire, even if the recommendations they make don’t do anything to keep your site safe.
1. Moving or Hiding ‘wp-admin’ Will Stop Brute Force Attacks
Brute force attacks occur when malicious bots hammer your login pages over and over attempting to guess your username and password in order to get admin access to your website’s back-end. From there, they can lock you out, compromise your data and deface or even take down your website. Most commonly, these bots try common usernames like “admin” alongside tens of thousands of passwords, hoping that one of them will work and allow them access to your site.
Because these bots target the login pages of your site, the logical next step for many users is to look for a way to hide their site’s wp-admin folder, or at least their login page. There are many plugins in the WordPress repository that help you accomplish exactly that, and we here at Wordfence get regular requests from our users to incorporate that feature into the plugin, too. And while it may be something we look into adding to the plugin in the future, we haven’t yet made it a priority for a couple of very good reasons.
First, many plugins and website features depend on the wp-admin folder being exactly where they expect it to be, and when anything changes the path of that folder, the plugin or feature can break. This is why we recommend changing or password-protecting the wp-login.php page only when users ask us about this approach.
Secondly, and perhaps most importantly, this approach is a way of implementing what’s called “security through obscurity” – an attempt to increase the security of your data by hiding an access point. Depending on something in your site being hidden or secret is generally not considered a best-practice approach to online security, and the truth is that any hacker who has the tools to try to break into your site will also be likely to easily find where your login page is hiding, no matter where you put it. It’s just not a very effective way of adding a layer of security to your website, and may be more trouble than it’s worth.
Lastly, as we reported in on this blog in January, the majority of attacks don’t attack the login page that you use to protect your site. Instead, they attempt to log in via XMLRPC, which is how other applications log in to communicate with your site.
2. Changing the WordPress Table Prefix Will Improve Security
A couple of years ago, we started seeing a rise in popularity for the idea that changing the prefix of your WordPress database tables would help prevent SQL injection attacks on your site, in which the attacker uses a vulnerability in one of your WordPress plugins or themes to gain access to your database. (You can read more about how a SQL injection attack works over on our Learning Center article about them.) The idea was that if you changed the database table prefix from the predictable and default “wp_” to something else, it would somehow prevent these types of attacks.
We’ve covered this topic at length fairly recently, but the bottom line is that there’s no reason to believe that changing the database table prefixes will do anything to improve the security of your site, and doing so may actually put your entire site at risk if it isn’t executed perfectly the first time. We consider it a form of “security theater” – actions that make you feel like you’re doing a lot to improve the security of your site while actually accomplishing little or nothing to that end. The best protection against SQL injection attacks is a three-pronged approach of using a powerful Web Application Firewall, monitoring your site continually against malware and keeping your website’s plugins, themes and core files up-to-date and patched – all of which Wordfence and Gravityscan help you accomplish.
3. All That’s Needed to Lock Down a Site Is a Secure Username and Password
Certainly, using a strong password and unique admin username on your WordPress website is an important part of securing your site. After all, one of the basic tactics of hacker bots is to try a few thousand passwords with the default WordPress username “admin.” Simply by having your admin username be something other than “admin,” you’re already getting one step ahead of malicious entities that may try to break into your site, and if your password happens to be a long hard-to-guess unique string of a combination of capital and lowercase letters, numbers and special characters, that’s even better.
But the truth is that even if you have a secure username and password for your website, hackers may still be able to break into and take down your website using other means, such as security vulnerabilities in outdated plugins, data breaches or phishing.
Sites that aren’t protected by two-factor authentication, which sends a code to your cell phone every time you log in as an admin, are especially at risk of exposure. Secure usernames and passwords are a valuable line of defense against hackers, but they can’t be the only strategy you use to secure your site. Implementing two-factor authentication on your website adds a crucial second layer of security to your login credentials that make it that much harder for the bad guys to break in.
4. My Site Isn’t Important Enough to Be Interesting to Attackers
Many website owners mistakenly believe that their sites will enjoy a relative degree of safety from hackers because they also believe that hackers only target high-profile companies, and their businesses or websites are too small or unimportant to be a target.
Unfortunately, that’s just not true. According to a 2014 study, 60% of all online website attacks were small and midsize businesses. An even more sobering statistic: because these smaller online entities simply don’t have the resources or safety nets necessary to immediately rebound from these attacks, another study found that 60% of small businesses that suffer a cyberattack close down within the year. If anything, because your organization is small, your website may have fewer security resources in play and be more vulnerable than larger, more robust websites.
Your website doesn’t need to have a high profile or millions of visitors to be useful to a hacker. Once they’ve gained access to your site’s admin capabilities and back-end, they can wreak all kinds of havoc, including defacing or outright destroying your site, using your server to send spam to other people, distribute malware to your visitors, post link spam or redirect your visitors to a malicious website.
The reality is that no website is too small to be hacked, and all website owners should take every precaution they can to protect their data from malicious hackers and cyberattacks.
5. My Site Is Safe Because It Has an SSL Certificate
An SSL (or Secure Socket Layer) certificate adds a layer of security to the communication that takes place between your website and your visitors. Having an SSL certificate on your website is an important step toward ensuring that communication between your site and your visitors, especially visitors that submit sensitive personal data such as a credit card number or their contact information, is encrypted and unable to be viewed in plain text in case of a data breach on your website.
Sites with an SSL certificate have URLs that start with “https://” instead of “http://” to indicate that it’s properly encrypted. Many customers know to look for that padlock symbol in their browsers that indicate a site has SSL protection, and in January of 2017, Google started requiring HTTPS for secure data in Chrome browsers, visibly marking any site that didn’t have one while collecting personal information as “Not Secure.”
Unfortunately, the security that an SSL certificate offers your website is purely transactional: it protects the information being passed between your site and your visitors, but – crucially – not the data housed on the site itself. Without a Web Application Firewall, up-to-date plugins and software, and other endpoint security measures, your website will remain completely open to hackers even if it has an SSL certificate – and that could still put the customer data stored on your site at risk.
6. My Site Uses a CDN or Cloud-based Firewall, Which Is the Same as the Wordfence Firewall
Content delivery networks (CDNs) and cloud firewall providers such as GoDaddy/Sucuri and Cloudflare can offer your site protection by rerouting traffic to their servers, filtering the traffic based on their firewall rules, and then only forwarding the traffic that passes those rules over to your website. The expectation is that this route will hide your website’s actual server origin because anyone visiting your domain name gets automatically forwarded to the cloud firewall provider’s servers instead of yours.
The reality is that it’s extremely easy for virtually anyone to bypass cloud firewalls by discovering your website’s originating IP address and attacking it directly. Keeping your site’s originating IP address a secret is extremely difficult, if not altogether impossible. This is a well-documented problem with cloud firewall solutions, and we’ve written about this in detail before, if you’d like to see exactly how this works, but the bottom line is that endpoint security is a much more robust and reliable approach to website security. Wordfence supports protecting your data where it originates as the best front-line defense against potential attacks.
7. WordPress Itself Is an Insecure Platform
WordPress is the most popular content management software right now, powering more than one in every four websites on the Internet, and being used nearly 4 times as often as Drupal and Joomla combined. Due to its popularity, WordPress has endured a few high-profile security scares in the past few years. A WordPress exploit or vulnerability means that a much larger base of websites are put at risk, and as a result, many people have come away from these scares with the belief that it’s an inherently insecure platform – but this is simply not true.
While it may be the case that WordPress may be subject to more attacks than less popular CMSs, this doesn’t mean that WordPress is inherently less secure. On the contrary, because it powers millions of websites, WordPress has a passionately active international community of users and developers that collectively work 24/7/365 to find and patch any possible security vulnerabilities both in the core software files and its huge ecosystem of plugins and themes. Because of this enormous global community – which no other CMS even comes close to matching – almost as soon as a potential threat or vulnerability is identified, there’s a fix or a patch made available.
The overwhelming vast majority of security compromises and hacking incidents – nearly 80% – are the result of outdated software and/or password exploits – that is, they’re due to either a weak username/password combo, or due to a vulnerability that the site admins failed to patch or fix in time, not an inherent flaw in the software itself. Put simply, the easiest and most common points of entry into a website for a hacker will always be via a username/password access exploit or an outdated plugin, and this will hold equally true for any CMS, not just WordPress. You need to keep the software that powers your website as updated as humanly possible. This is why one of the core features of Wordfence is its alerts, which let you know the moment that an update your site becomes available, so that you can easily stay on top of keeping your site patched and current.
Conclusion
Maintaining and optimizing the security of your website can seem like a very daunting and complicated undertaking. Site owners may struggle to parse an endless stream of information and advice that sometimes may even conflict. Determining what will really work and what is simply “security theater” can be extremely challenging, but armed with a good endpoint firewall, a secure username and password with two-factor authentication, and the most up-to-date site software, you can get a lot of peace of mind knowing that you’re making it as hard as possible for anyone to get through your website’s well-maintained defenses.
Comments
9:07 am
Nice! Thx for the effort.
9:29 am
Very informative article. Can you please address the claim that Wordfence slows sites down by working on the site instead of in the cloud?
Thanks.
12:40 pm
Thank you Cathryn - glad you enjoyed it! To answer your question, Wordfence is pretty lightweight, and I can tell you that I've personally installed Wordfence (both free and premium) on over 450 websites without noticing any kind of increase in page load times as a result.
7:12 am
I have a cheap shared hosting setup with a company whose customer service ratings have tanked in recent years. My traffic is very low. Sadly, it took me 1.5 years to figure out -- with no help from my web hosting provider -- that almost ANY (even manual) HTTP traffic would shutdown my site if a WordFence scan was running. My guess is that this scenario would apply to any kind of scan, and maybe even be worse with a backup process.
My point is that WordFence may have been the trigger, but it was not the cause. My suggestion is that people on cheap shared hosting plans consider that web hosting companies have "secret" limits that they enforce with their own software, even though they promise the lie of "unlimited" everything.
9:33 am
1. Regarding #1 about hiding WP Admin, I agree, but I wonder about simply blocking wp-login.php using HTTP authentication as listed in WP Codex?
https://codex.wordpress.org/Brute_Force_Attacks#Password_Protect_wp-login.php
Oddly, in another place they recommend protecting entire wp-admin but excluding files that might be required for public-facing site to function.
https://codex.wordpress.org/Hardening_WordPress#WP-Admin
My thought is that if you don't have a customer-facing login over wp-login.php, why have your CMS login accessible to the internet at all? Seems logical to restrict it to either certain IP addresses or add an HTTP password.
10:55 am
Hi there Thomas! Thanks for your feedback. Some plugins need a customer-facing login or wp-admin to be public, so ultimately whether that's the right call for your site will depend on your particular setup. It's not wrong to do it - it's just not a security panacea either, and may not be right for every site. And it definitely shouldn't be the main or only way a site is protected against security threats!
9:35 am
Hi there, nice article.
Tho I'm one of those who change/restrict access to wp-login.php I have to mention that the article is very useful. For me it works because any hit which is targeting the wp-login page is automatically banned.
I have a single question.... why we, as potential targets for hackers don't have the necessary tools/software/opportunity to "punch back" ? --- Adding more and more security layers as the hackers and hacking techniques evolve our website/service will run a 80% secured platform and not a website. This days the only thing we can do is to make sure our website is secure enough and turn the other cheek when we are hit. In my own opinion is way to passive, I'm more of "you wanna hack my website... take this and this... and this" -- playing nice is not always the best approach ... assisting passively to malicious attempts hoping that all our security measures will protect the website is a bit "outdated".
Again this is my own opinion
11:37 am
Thanks so much Dan! Restricting access to the login page can be useful for some users. As for why we can't "punch back" - that's a great but complicated question! There are legal and ethical ramifications to retaliating against potential hackers and we can't really recommend any tactics in that vein for that reason. But while no website will ever be 100% secure, we think you can get a lot closer than 80% using the kinds of security best practices we recommend in this and other articles. In the case of WordPress sites, often just using two-factor authentication and a secure username and password will put you way ahead of the majority of WordPress users. This isn't outdated; it's actually in line with industry best practices. Hope that helps!
9:38 am
Thank you, always very informative information.
9:42 am
EXCELLENT - as always! This sums up my communication with customers in a very nice way. The confusion regarding security in reference to SSL Certs and CDN's is a part of the more complex myth-taken myth-understandings! Those ideas blended with "Cloud" meme - that many seem to believe is magical floaty space guarded by angels, are constant sources of frustration in dialogue with customers regarding process, practice and architecture. It helps to have a service and resources provided by your most credible team!!
9:59 am
Appreciate the overview of these security issues. You really help debunk many of the myths that seem to be prevalent in our developer community.
One of the really difficult issues is keeping all these functional plugins up-to-date, especially when you manage a very large number of client websites (over 60 sites in our case). I have a routing folder setup in Outlook so that WordPress alerts (and WordFence alerts) appear in a special folder. Every day I receive over 100 update alerts of one form or another about plugins that need updating. Since an average website for us might have 10-12 plugins, and some plugins will update at least once a month, you can see how it adds up. We have one very prominent plugin used by millions of WordPress sites that has had 5 separate point-one releases in the last 30 days. We could probably hire a "plugin updater" full-time just to keep up with WordPress, Theme Framework and Plugin updates.
I wish plugin developers could be more predictable with their updates. Having run a major software organization earlier in my career, I know that bugs and patches are part of the business. But, when you have to update a plugin a half-dozen or so times in a month, there's something wrong.
Thanks for all that you do at WordFence. We value your software and have it installed on all of the sites we manage.
Chief Digital Officer
Scottsdale, AZ
12:36 pm
Hi Jim - I'm sure you are aware of ManageWP to help manage core, plugin and theme updates to multiple WP sites. I use it as part of my business, and can't recommend it highly enough - it has great tools to push updates to multiple sites concurrently.
Thanks again to the Wordfence team for another great article, and your ongoing delivery of the very important plugin that helps keep our sites safe!
10:21 am
Thanks for the GREAT education, Andie: The perfect compromise between tech lingo and an "easy read", highly informative and educational!
1:02 pm
That's awesome to hear, thank you, Peter!
10:21 am
Hi Mark,
Thank you for this write-up! Totally agree with you on the part of the damage caused by outdated plugins. There are a lot of plugins abandoned by their authors and do not get updated for years, and they sit there, ducks for anyone looking for vulnerabilities. Site owners usually do not notice outdated plugins.
It would be great if Wordfence integrated a feature that details how long it has been since plugins were last updated and if they were tested with the latest version of Wordpress.
10:23 am
Thank you! I've done some of these, and wondered if they were really necessary or at all helpful. I appreciate a better understanding to make a more informed decision on whether I continue to do them in the future.
10:32 am
Incredibly interesting post, thank you! I especially liked the part about Wordpress getting a bad rap because it is inherently not secure. I agree with you on the huge user and developer communities passionately patching vulnerabilities.
10:37 am
Hi - In general, thanks and this is helpful.
I think I've seen you put out number 1 before. I disagreed then and I disagree now.
Just saying that "security through obscurity" is not considered best practice and dismissing this measure for this reason doesn't cut it for me. Yes, "security through obscurity" is not best practice. Can it help to reduce risk? Sure - sometimes and this is one case where it does.
I also don't buy the assertion that the majority of attacks don't target wp-admin but rather XML-RPC.
Why do I think both of the above? Because monitoring bot attack live traffic using your plugin has demonstrated as much to me.
There are frequent bot attempts to target the default login page, but not my renamed one - is this the totality of my security controls? No, but you seem to be characterising it as irrelevant and it doesn't seem to be at all.
There are XML-RPC attempts as well, but not to the exclusion of targeting the admin login.
Creating a different admin login won't stop a skilled human attacker, but doesn't mean it's not worth doing for the bots, does it? It's also been zero trouble.
12:52 pm
Hi there Stuart,
All good points. This post was intended as a sort of a high-level overview of these seven scenarios, so we couldn't dive in as deeply into each one as we could have in a stand-alone blog post for each topic. Fortunately, we do have a more in-depth analysis of this very topic and the questions you've raised in a previous blog post which you can find here. Ultimately, hiding your wp-admin may cause a lot of issues in certain setups and still leaves XMLRPC open as a vector for attack, when most bots attack both. The best line of defense is always going to be to implement a robust multi-pronged security solution (like Wordefence!) that will intelligently block all brute force attacks from every angle and across every authentication method.
11:14 am
We know from bitter experience that being a very small low-traffic site doesn't stop you suddenly finding (through 10s of 1000s of 'failed delivery' messages, and our hosting provider closing our site down shortly after) that you've had a bank login phishing site embedded deep in your file structure.
11:31 am
It amazes me to have seen the number of WordPress sites that do not implement the very basic elements of security. I have found moving my client's login page while also incorporating a query string has worked very well. WordPress is definitely a fantastic CMS platform choice.
11:36 am
What about the hosting? Any advantages there? I know that a lot of hosting companies are Selling SSL and scanning as a value add - It would be nice to just have the hosting company take care of some of the security.
11:42 am
That's a good point, and some of the managed WordPress hosting solutions do provide some security services for that very reason.
11:38 am
Thomas, we used a plugin which renamed wp-login.php for many years.
However, over time, we found it wasn't worth the headaches that disconnecting the regular login processes causes. In addition, that didn't stop the performance problems (many 500 errors per day) on our good-but-shared web hosting. Plus, the attacks accessed login capability through other means, and meanwhile, every attack took a toll on our performance.
After recently loading WordFence, however, and increasing the blocking time from 5 minutes to 5 days or longer -- and permanently blocking egregious hackers via cPanel -- our sites' performance is excellent.
We have considered getting the pro version of WordFence, because if we could block our (English-language) websites from Russia, Ukraine, and Turkey, about 90% of the hacking attempts would be stopped before they ever happened. However, for us, the pricing is prohibitive. That said, we're still really grateful for the lite version of WordFence.
12:46 pm
Hi
Wanted to say very big thank you for the Wordfence team you are doing great job!
And for hackers a message, you lazy people go grow potatoes.
12:53 pm
Thank YOU for the kind words. "Go grow potatoes" may be my new go-to insult for everything. :)
12:11 pm
I love the research that takes place here on this blog. I think Cyber Security is the one complicated topic that most people won't tackle. I work in IT and a lot of it is complex and hard to understand, let alone for someone that really isn't technical but want's to run a website.
Even understanding 2-factor, which applies just not only to website security, but even for any website that you login to for any purpose, whether it be banking, paypal, Google, etc. 2-factor should be enabled everywhere. Use of complex passwords should be enable everywhere. Securing your home router is also necessary as well as being vigilant when surfing the net. VPN, Anti-virus, and on and on... It's a lot to manage. So the work that you all are doing here at Wordfence is quite remarkable and in this interconnected digital age your expertise and this blogs value is just going to continue to go up. I believe you all are serving at the highest levels in the tech/online community so thank YOU!
Speaking of Web App Firewall, I am having an issue with activating my WAF on my Wordfence installation. I've submitted a support ticket, but in short, when I go through the options of selecting my web server instance, I can select it and continue, but nothing happens after that. I've been trying to get it to work for a few weeks now before submitting a ticket. The web host and my developer recommended reaching out to the developer of the plug-in, YOU! :-)
Thanks so much,
Dean
12:44 pm
Thank you so much, Dean! Cybersecurity is a deeply multifaceted topic, and so it can seem very complex at times - but our hope here at Wordfence is to provide resources so that it isn't hard to understand, and is accessible to as many people as possible instead. We look forward to helping you via the support channels - I have no doubt we'll help you get to the bottom of what's going on! :)
12:47 pm
I know I'd really like the option added within the Wordfence plugin to change the location of the login screen.... I've been wanting that for a while now...
12:54 pm
Shane,
It's a feature request we get a lot, and we may implement it somewhere down the line, but alas it's not currently in the pipeline. Thanks for the feedback, though!
1:43 pm
Excellent! Personally I believed in some myths until now. :-)
2:16 pm
Having had sites hacked in the past, I've become a great deal more conscious of security, and I'm glad to hear that I haven't fallen for any of the myths. I think the biggest problem with wp-login access is that the constant bot-hacking attempts put a load on the server; with lower powered servers, it can really impact load time. Since I'm the only one who logs in on my sites, I back up the wp-login.php and replace it with a file that simply says "Go Away". It's inconvenient to have to change the file name back when my login expires, but the results on my VPS (where I have three WP sites) in terms of server load has been significant. Since I started doing it, it has knocked several seconds off the page load time, and when WP updates and replaces the file with a real one, the slow down is immediate and obvious.
3:22 pm
Thanks for the article, fascinating.
May I ask if Wordfence Premium can work in conjunction with SUCURI Cloud-based Firewall?
And Wordfence Premium + CloudFlare CDN?
4:16 pm
Yes they all work just fine together. Wordfence has specific advantages because it is an end-point firewall. So we know if a user is signed in or not, what access level they have and what action they're performing within the application. Cloud firewalls do not have this data because they run on separate servers out on the Internet. So their firewall rules are far less sophisticated than ours are because they simply don't have as much data as we have.
Mark.
8:06 pm
It's late and I may get this wrong, but I believe Wordfence has an option to allow one attempt at a login, after which the user's locked out for a period of time. I checked that option because I'm the only one who needs to get in and my home computer remembers the password. That seems to have cut down on the brute force attacks (plus my sites automatically update WP). *Fingers crossed*
8:01 am
Absolutely, Bill - that's a good idea in cases like yours, and generally speaking, having strict login attempt and rate-limiting rules set in Wordfence are a powerful approach to cutting off any username/password access brute force attempts at the knees. I highly recommend monitoring the usernames used during login attempts and adding those to the "Immediately block the IP of users who try to sign in as these usernames" field in Wordfence > Options > Login Security Options. I add things like admin, webmaster and design by default to my WP installs, as well as the URL of the website without the .com part (for example, if your site is bestwebsiteever.com, you would add the username bestwebsiteever), since those are the most common. We may do a blog post about strategies like this soon - keep an eye out! :)
8:45 pm
Thank you! This post certainly helped realize some of my misunderstandings with site security. It would have been great to suggest alternatives to each of these ineffective security measures. Awesome post!
8:14 am
Thanks, Shiv! I recommended a few alternatives in most of the points, but I think the broader takeaway is that no one single security measure will secure any website. Cybersecurity is like an onion: there are many layers! :)
2:11 am
So very true! If only more people could reads this great article on this! I see all seven all of the time when working on projects and also many more non-solutions all of the time. I think I forgot about five more but still may I add:
1. Not removing the Hello World post is a risk, hackers will see that you use WordPress.
2. Hiding GUI elements for other non super admin admin users.
3. Disabling FTP for admin by not storing the password in WordPress.
#1 is an ill assumption that assumes that WordPress can not be recognized easily if this post that is created at install is removed. Sure it will not be discoverable via Google dorks but this is a discovery method but it’s so freaking easy to see if a website is WP or not. Just looking at the code and the inclusion files in the html head is always enough.
#2 It doesn’t really make things accessible in such a way that it can not be undone by anyone with normal admin role. It makes for an ill UX for sure and maybe some hackers will also give up and rather hack the next site because it works crappy.
#3 One can argue that it’s safer and prevents privilege escalation when an admin account is compromised and hackers are able to login as admin. My own take on this is that the collateral damage that this method brings along is worse than then the risk it tries to counter. This because in real life most sites are installed and developed by someone once and then at best it’s maintained by the same person or company but sometimes this is not even the case. The people that work with the site on a day to day bases will not be involved with updating the site etc even if they are admins. And if they would be willing to run updates then they can't because of the missing password. What happens in most cases is that critical updates launched via the auto install function doesn’t work and that these sites keep running compromised versions of WP for weeks or months after the update. This is sort of penny wise and pound foolish I think.
I recommend that we leave the concerns there in the stack where the belong and make those managing that part of the stack responsible. Like hosting, maintenance of code etc. Use a WAF (Cloudflare), optionally use an application firewall like WordFence if you like and select a managed platform for your hosting like serverpilot. Don’t use shared hosting and don't be lazy and create dedicated ftp and database user per website. If your really bad ass use two database users with read access for the one and write access for the other and then only use the first one on the front end facing part of the site.
Also, and very important I think: don't install every freaking half baked plugin and/or theme! Also way out pro’s and cons every time and accept that some things cost like a few dollar a month and not all can be free if you're a serious business. Nice table borders are not worth having your webshop being hacked over I say.
Gr Daniel
7:02 am
Thanks for the great article and great service you provide to the WordPress community! I love the clarity and solid information that ALWAYS comes from the Wordfence team.
3:49 am
Thanks for teaching us time and time again.
4:26 pm
I bought a bunch of API keys for your pro version for my clients and our websites and I never read your blog before. I am starting to read it because I want to see if we are setting everything up correctly. What I have found is a clear level-headed way of thinking on security and the mechanics behind it. I will keep coming back to listen if you have more to share. Thanks for the good posts.
7:36 am
What about the best practice for securing a WordPress login using the admin screen? If logging on over HTTP, wouldn't an all important admin password get sent over plain text (and be at risk)? Can you offer advice on whether an SSL certificate is necessary to protect a login password from being exposed while connected to a public Wi-Fi network? This could be for example when in a hotel or cafe and connecting to a WordPress site over Wi-Fi.
Of course using a VPN is a smart solution which can protect all web browsing data while traveling and using public Wi-Fi networks.
11:20 pm
Thanks for a detailed explanation of what security is all about. I was hacked one time and it took me weeks to get all of the spam links cleaned out of my site.
6:50 am
I am continually invstigating online for ideas
that can assist me. Thank you!