Premium WordPress Support

Professional Consulting & Support Services

By

Common WordPress Mistakes to Avoid

Photo Credit:
Photo Credit: carpediemotivation.com

Committing mistakes in WordPress may lead to problems with your site security. In this article, we are going to identify some WordPress mistakes and how you can avoid them on your WordPress site.

Using admin as the login name

By changing the default WordPress login name admin makes it harder to hack into your site. Once you use admin with a less than fortress-strong password, you’re asking for a hacking attack.

Using an administrator to post content

If it happens that your site administrator is posting content, then their username is displayed there. Put your administrator at the back-end of your site and create a contributor account as an author or editor. While writing the content, you must post it under a different name.

Using ‘wp_’ as the table prefix

By default the tables in WordPress start with ‘wp_’. However, you can create another predictable way for hackers in your site options table as ‘wp_options’. During installation of the wp-config.php file you can change it manually or in the form fields.

Salts and keys are not replaced

Salts and keys are held in the wp-config.php file which are used to authenticate users who logging in along with their machines. At some time, session cookies could be stolen to allow hackers pretend to be you. You can generate them and copy all the information into your wp-config.php file. (Click here for the information).

Backups not getting done

If you do get hacked, you can restore your system to a previous version but only if you’ve backed everything. There are various ways to do this such as using VaultPress or a free solution like BackWPup.

All categories, no tags

Everything must be planned and organised, particularly if you have a content-heavy site. You can use tags to link your content and limit the number of categories to have a simpler structured site.

Ignoring the cache

Caching is a significant to your load times which save the final HTML markup on a user’s computer and there’s no need to keep going to your database every time a page loads. You can add plugins such as W3 Total Cache or WP Super Cache to help with your site.

Not updating from time to time

If you are on an older version of WordPress, there’s probably a loophole that will be fix in the latest one. Download it now.

For further information about this, visit this – WordPress Mistakes to Avoid.

By

4 Known Ways to Achieve Better WordPress Security

Photo Credit: 4 Little Known Ways to Achieve Better WordPress Security

There are known methods of enhancing your WordPress, as maintaining both of the security vs. usability equation.

  1. Strengthen WordPress Security by Limiting Access

The iThemes Security plugin offers the ability to close your WordPress Admin section and set it inaccessible during set times. From the Settings page, visit the Away Mode section to activate.

  1. WordPress Security Doesn’t Require You to Reinvent the Wheel

iThemes Security allows you to eliminate this list of “bad actors” from accessing your WordPress website. From the Settings page, visit the Banned Users section and click Enable HackRepair.com’s blacklist feature.

  1. Eliminate Any User or Bot Attempting to Do Your Website Harm

Visit the Settings page in the iThemes Security plugin. Visit the Brute Force Protection section and click Enable Brute Force protection. Check the box to activate Immediately ban a host that attempts to login using the “admin” username.

  1. Close New Security Holes in WordPress

iThemes Security provides a very simple for those WordPress site owners. From the Settings page, visit the WordPress Tweaks section. In the Multiple Authentication Attempts per XML-RPC Request section, select Block (recommended).

In a way of enabling these known WordPress security tips, you can take another step towards protecting your WordPress website. Make sure you subscribe iThemes for further security tips.

By

Akismet 3.1.5 Fixes Critical XSS Security Vulnerability

AkismetFeaturedImage

Make sure your running version 3.1.5 if you are using Akismet to battle comment spam as it patches critical security vulnerability. Due to the nature of the bug, the Akismet team pushed out auto updates to sites that can accept them. According to Sucuri, sites using Akismet 3.1.4 and lower and that have the Convert emoticons to graphics on display option enabled, are at risk. An attacker with sufficient knowledge of WordPress’ internals could insert malicious scripts in the Comment section of the WordPress backend. So far, Akismet developers don’t have any evidence that the vulnerability is actively being exploited in the wild.

For more details about the Akismet Security, kindly visit and check at Akismet 3.1.5 Fixes Critical XSS Security Vulnerability.

By

Have you heard of Clef?

Our technical colleagues at Clef got in touch with us and we finally managed to publish the interview with them. Clef is a wonderful product that enables two-factor integration with your WordPress website, and is also available for all of you hosted with our friends on a SiteGround Managed WordPress Hosting.

 

Tell us a bit about yourself and how did you get involved with WordPress?

Hi everyone! My name is Jesse and I’m one of the founders and the head of product at Clef. Essentially, that means that I get to talk to our users every day and lead development on all things you interact with. It’s awesome. Before Clef, I was in school at Pomona College, but I dropped out after two-years to focus full time on killing passwords.

The first time I used WordPress was in my junior year of high school. We had a newspaper, but one of my friends and I wanted something that students could actually interact with in a real-time way. We decided to create a blog, and I decided to run it on WordPress. We eventually grew to having ~7 writers and I was super impressed with how easy it was to manage everyone and everything with WordPress. Pretty great introduction. I used WordPress on-and-off after that to build websites and when we started Clef I knew it was the first platform we had to build for.

How was the Clef idea born – what were you struggling with prior to building Clef?

Clef actually came out of a bunch of work that our CEO, Brennen, did. Back in 2011, he was working at Adobe on their Strategic Alliances team right after Steve Jobs wrote the letter that killed flash on the iPhone. Since companies like Adobe used flash to identify users for partner advertising, he was part of a team that was tasked with figuring out new ways to identify users on mobile devices. Around that time, LinkedIn had, what was at the time, the largest password breach ever (an event we think of as the beginning of the “era of breaches”). Brennen saw the juxtaposition of the failure of passwords with all the work he was doing on mobile identity, and realized that our phones could do a *much* better job of identifying us (both security and usability-wise) than the username and password infrastructure. He went back to school at Pomona, started working with a professor studying security through usability, and wrote a thesis on phone-based identification. Eventually, he recruited Mark (our CTO) and I to join the project and we turned his thesis into Clef. A year later, we moved up to the Bay Area and launched the product.

If you were to explain to a blogger or a non-technical user Clef, what would be the key selling point (in a sentence or two)?

Going to break the rules and do two selling points here: security and usability. With Clef, you never have to remember passwords for your WordPress sites again *and* every site is protected by two-factor authentication that will keep you safe from all the brute-force breaches you’re hearing about in the news.

Are there any hosting restrictions or limitations, for example is it applicable for shared hosting customers, too?

Nope! Clef will work on any WordPress site out there (and if you have any issues, just email us at support@getclef.com and we’ll get the problem resolved ASAP).

How about the more technical users? What is the complete flow of Clef, do you store any sensitive information on your servers?

Clef wraps a technology called public-key cryptography. Developers have been using public-key cryptography to identify themselves for the last 20 years (every time you push code to Github or SSH into a server, you’re almost certainly using it). In our architecture, the “private keys” (the valuable credential information) are generated, encrypted, and stored on the phone — they never leave. The only things we store are the “public keys,” which are used to verify your identity, but can’t be used to impersonate you. Even if all of them were exposed, an attacker would be no closer to logging in as you. This distributed architecture eliminates all of the attacks we commonly see against passwords and makes the economics of compromising users much less viable for attackers. Rather than being able to hack a database and get millions of passwords (which they could sell for a fraction of a cent each), they’d have to target every user individually.

How safe is that second step verification process in practice, relying on a separate device?

Very. The great thing about our second-factor (the PIN) is that the only way it’s vulnerable is if an attacker already has your device. If you ever lose your phone, you can just go online and deactivate to render it useless for logging in with Clef — in the meantime, your PIN protects you from an attacker trying to impersonate you.

What are the future plans for Clef? Would you follow the freemium model, or switch to paid packages for all of your plans?

Clef will always be free for WordPress users and sites — we all love the community so much and think that it’s really important to increase the default level of security for new WordPress users. Limiting that goes against our values.

In the next year, we’re going to be expanding our platform beyond one-click installations like WordPress and into more consumer-facing login pages like the ones you use every day (think financial and health online services). We’ll be building our the necessary APIs, documentation, and developer tools to make custom integrations really easy and then working with early stage companies to offer low-cost, super usable two-factor authentication. If you’re reading this and that perks your interest, shoot me an email at jesse@getclef.com.

Anything else that you’d like to share with our readers?

I’m always around on twitter at @jessepollak and by email at jesse@getclef.com — if you have any questions, or need any help getting setup with Clef, don’t hesitate to reach out.

By

WordPress Security Vulnerability Discovered in the TimThumb Script

Security is always a big issue for every open source platform as attackers spend a lot of time searching for loopholes in the code. WordPress is no exception in this and every day, security vulnerabilities come up. Many of these are however discovered and silently fixed by the team at Auttomatic before they even reach the community.

Late last month, a major vulnerability was discovered in the TimThumb 2.8.13 script which is widely used by WordPress theme and plugin developers. The script has a feature called “webshot” that, if enabled, gives an attacker the ability to run commands from a remote server. This means that an attacker can access, modify and even remove your website files without having to login to your cpanel.

timthumbsecurity-teaser

This is not the first time that the script has been plagued by a security exploit. Two years ago, large scale security attacks were launched against the script and hundreds o websites were brought down by hackers. This however did not affect its popularity as it is still used in all themes from Themefy, the WordPress Gallery Plugin and several other third party services.

Security experts at Sucuri have already made a breakdown of the exploit here.

Although a fix is yet to be released as of now, there is some good news in that the Webshot feature is by default disabled. This means that your site may be secure despite running the script in the active theme or plugins. It is however important to confirm that the Webshot is actually disabled and correct that accordingly. This can be done by simply searching for the word “WEBSHOT_ENABLED” across all your themes and plugins to confirm that it is set to false as shown below.

define (“WEBSHOT_ENABLED”, false);

This simple fix is the only option that you have if you want to secure your site from yet another TimThumb exploit. Themify has also addressed this in all their themes and all you need to do is to run a theme update.