Forum Replies Created

Viewing 10 replies - 76 through 85 (of 85 total)
  • Thread Starter jasonbear

    (@jasonbear)

    “You mean a security plugin has never told you your website is hacked.”

    No, I mean that all of the 200+ sites that I’ve managed over the last 4+ years have never been hacked. No defacing, no redirections, no unknown IP logins. Not once. I guess I could just be a very lucky guy, but I’m going to assume that it’s at least partially because of the brute force protection and automatic IP bans provided by the Wordfence or iThemes Security plugin. All of the hacked sites that I have fixed, however, have not had a security plugin installed. Their only line of defense was an up-to-date WordPress. Some were up-to-date; some weren’t. Yes, some of them were victimized by a vulnerability in outdated code, but most were brute forced (even when running the latest version of WordPress).

    I think that we’re addressing two very different things here: 1) vulnerabilities in outdated code and 2) brute force. Yes, outdated/vulnerable code in WordPress core or a plugin generally won’t be “pre-patched” by one of the security plugins. However, the plugins do an exceptional job of stopping what may be the most common form of attack: brute force. As you know, in the case of brute force attacks, having the latest version of WordPress doesn’t matter. The hackers are coming through the front door. They are simply knocking hundreds or thousands of times until they “guess” the password. It’s a numbers game. The plugins stop the brute forcing IPs automatically, after a set number of failed login attempts. The default settings are effective, and the advanced options are even better. (Plus, the plugins also have settings that make it impossible — or at least much more difficult — for hackers to acquire one’s username. Hackers are left with only two options: using the “admin” username or running a secondary guessing game in addition to having to guess the password.)

    Why wouldn’t WordPress do whatever it possibly can to help mitigate brute force and other attacks? Even if it mitigates only brute force attacks, why not include a security plugin? If it’s a matter of not wanting to rely on a third-party plugin, why not either buy Wordfence/iThemes or integrate your own, in-house brute force protection?

    Thread Starter jasonbear

    (@jasonbear)

    Can you please elaborate? That has not been my experience at all. I have never had a personal or client site get hacked with one of those security plugins installed, even with sites that have WordPress core that is many versions (and sometimes years) outdated.

    Also, how can hackers crack the password if their IP(s) gets blocked after only a couple of failed login attempts?

    Thread Starter jasonbear

    (@jasonbear)

    Hello, Andrew,

    Yes, WordPress is secure when and if it gets patched. I feel that blaming Webmasters for not keeping their personal sites updated is sort of sidestepping the bigger problem. The bigger problem is that when thousands of Webmasters every month get busy with other projects, get a new job, have a baby, get sick/injured, or even die, their WordPress installs do not get updated. At that point, their sites become both directly vulnerable to damage and pose various risks to other sites/companies.

    Keeping WordPress core updated is only half of the solution to the WordPress hacking problem. The default, “out-of-the-box” settings in each of the plugins that I mentioned “pre-patch” many weaknesses and potential vulnerabilities that make keeping WordPress core updated not nearly as crucial. Plus, they offer advanced settings (like changing default folder names, applying local and network brute force protection, strong password enforcement, etc.) that can make a WordPress site virtually bullet-proof, almost regardless of WordPress version. These plugins remain effective even when the WordPress install becomes out-of-date. For example, in the case of network (i.e., crowd-sourced) brute force protection, even if their passwords are not strong, brute force protection makes it extremely unlikely that hackers will be able to guess/crack the password if the attacking IP gets automatically and permanently banned after only 3 attempts.

    So, irrespective of WordPress update status and password strength, why can’t a security plugin be included? An updated WordPress core and a security plugin don’t have to be mutually exclusive or seemingly adversarial; quite the opposite, actually. It seems to me like everyone would win . . . except the hackers.

    Thread Starter jasonbear

    (@jasonbear)

    By the way, someone changed my review from 1 to 5 stars.

    Thread Starter jasonbear

    (@jasonbear)

    There are better plugins for free. I am using one now. I have not received a single SPAM comment since activating. And guess what: the developers don’t send “give me money” emails and deceptive emails (such as “This email is about donuts and coffee”) every day.

    Thread Starter jasonbear

    (@jasonbear)

    I get happy every time I see a new update released, but it does not appear that any of my “wish list” options have been added. I’d love to these options:

    1. Disable Google fonts
    2. Disable texturization / wptexturize (automatic curly quotes, ellipses, em-dashes, etc.)
    3. Disable self-pinging
    4. Prevent Divi theme from printing version in header
    5. Disable/redirect “author” pages
    6. Disable/redirect attachment/image/file pages

    Thanks!

    • This reply was modified 7 years, 3 months ago by jasonbear.
    Thread Starter jasonbear

    (@jasonbear)

    Thanks, Frank. I’ll do that.

    In your opinion, what’s the best/fastest caching plugin that works seamlessly with Autoptimize?

    Thread Starter jasonbear

    (@jasonbear)

    Because I have personally seen it happen on 2 of my sites today. When I enable “Speed Contact Bar,” all of Autoptimize’s optimizations become disabled (i.e., no combined scripts/css, no minified HTML, etc.). As soon as I deactivate “Speed Contact Bar,” all of Autoptimize’s optimizations return. I reproduced this multiple times on each site just to make sure. The two sites are VERY different in terms of how their footers and such are constructed. One site is very old and one is very new (latest version of Divi).

    • This reply was modified 7 years, 3 months ago by jasonbear.
    • This reply was modified 7 years, 3 months ago by jasonbear.
    • This reply was modified 7 years, 3 months ago by jasonbear.

    Exactly. I also had to delete it because there is now way to disable it form admin views. It entirely block the Divi editing menu!

    Thread Starter jasonbear

    (@jasonbear)

    Excellent, BrotherS! Now, how do we directly clear meta_value of meta_key _lyte_xxxx under wp_postmeta by way of the WordPress admin?

    ??

Viewing 10 replies - 76 through 85 (of 85 total)