CAll Us: +1 888-999-8231 Submit Ticket

Be a Shark in Today’s Phishing Pond

Would you do business with somebody you don’t trust? Neither would your customers. Phishing attacks are at an all-time high, with 1.4 million new phishing sites being created each month so they have good reason to be suspicious of any website—including yours.

When it comes to gaining your visitors’ confidence, the rules have changed. On today’s fraud-filled web—it’s no longer who you think you are, it’s who a globally trusted third-party Certificate Authority (CA) says you are.

You Can’t Earn a Premium Reputation with Standard SSL

According to a PhishLabs report, within a 30-day window, 99.5% of HTTPS phishing sites had Standard Domain Validated or DV, certificates which offer only the basic level of encryption.

Thanks to browsers labeling websites with Standard and even Premium SSL certificates as “Secure”, online customers are drawing dangerous assumptions that even phishing sites are legitimate businesses—like you. So, why would you want to display to online visitors that you have the same level of security as phishing sites?                                               

Beyond the Basics

One of our earlier blog posts summarized the important industry changes that have made basic encryption a must for all web pages. All SSL Certificates offer encryption so even blogs and personal sites can meet this new global requirement. They also all provide basic trust features—including displaying HTTPS and the padlock icon in the browser bar. But, where they really differ is in the level of validation and visual trust indicators they offer.

This is huge. Why? Because, with online customers being mistakenly led to believe that secure and safe are the same thing (which they aren’t), you need to clearly set yourself apart from hackers. That means going the extra mile to prove—based on what a respected third-party has determined—that you’re a legitimate business. The best way to do that is with an Extended Validation, or EV, SSL Certificate.

EV Isn’t an Expense—It’s an Investment

Trust can make or break you online, even if your site isn’t built for e-commerce. Here are five reasons to invest in EV SSL:

 

  • Boost Confidence—EV enables the Green Address Bar, which is impossible to fake, making it the ultimate trust-builder. You’ll be giving your customers absolute assurance that you are who you say you are.

 

  • Operate with Complete Authenticity—CAs only issue EV SSL Certificates after they’ve validated your legal, physical and operational existence. Their comprehensive process even includes manual steps to ensure legitimacy.
  • Gain a Competitive Edge—With shopping cart abandonment rates soaring as high as 75%, you need to give visitors every reason to click your “Buy Now” versus your competitors. According to an article by monetizepros.com, 61% of shoppers said they decided not to purchase a product because it was missing a trust seal. Don’t be that guy.
  • Increase Conversion—EV SSL Certificates are statistically proven to increase sales. In a Tec-ED survey, 100% of participants noticed the Green Address Bar, with 97% being comfortable enough to enter their credit card information. In fact, 77% said they’d be hesitant to shop on a website without an EV SSL Certificate.
  • Promote Your Commitment to Their Safety—By putting EV’s visible trust indicators front and center, you’re showing visitors that protecting them is your top priority.

No matter what type of site you have, it’s time to stop appearing to online visitors like you’re on par with hackers. Trust us, if you hook them with truly authentic credentials, they’ll bite.

Posted in:
Security

Source link

OpenVPN Helps To Keep Your Magento And WordPress Dedicated Servers Safe

OpenVPN Helps To Keep Your Magento And WordPress Dedicated Servers Safe

Photo by Matthew Henry on Unsplash

When a user connects to your Magento store, they connect over HTTPS, a secure protocol that uses an SSL certificate to encrypt data sent between the shopper’s browser and the server that hosts the store. Without HTTPS, it is possible for a third-party to intercept the data, putting the shopper and the store at risk. But shoppers aren’t the only people that might need to access your store and its “front-entrance” isn’t the only way in.

In some cases, making a change to a store may require a developer or other professional to connect using a service like FTP. FTP is an old protocol that is often still used to upload files to a server. It doesn’t have any built-in encryption, so data is sent in the clear. There are several services a dedicated server hosting client might want to make available, but that are inherently insecure. Usually, insecure services like FTP are blocked by a firewall that prevents anyone from accessing them, but that may be inconvenient.

Retailers and publishers often work with third-parties such as design agencies or teams of outside developers. Remote employees may need to connect to the store while they’re in an untrusted location like their home or a coffee shop. Without a VPN, that’s a bad idea because sensitive data is sent over WiFi networks and the internet in the clear. It is trivially easy for a bad actor to intercept it, which is why we make OpenVPN available on dedicated server Magento and WordPress hosting plans.

The “VPN” in OpenVPN stands for virtual private network. A virtual private network provides the same protection as HTTPS to services that aren’t usually encrypted. When someone needs to connect to a store using FTP, they first connect to the virtual private network. You can think of the VPN as a tunnel through which other data is sent. That data is encrypted using similar techniques to the SSL-based encryption that HTTPS uses.

Once connected to the server’s virtual private network, the user can then log in over FTP and upload their files. The data they send will travel over the secure connection managed by the virtual private network. A man-in-the-middle attacker will not be able to intercept or alter the data.

Our WordPress and Magento dedicated server OpenVPN service is certificate-based, rather than credential-based, which means third-party users will need to have the relevant certificate on their machine. They won’t have to remember or use a password.

We make OpenVPN available on select WordPress dedicated server and Magento dedicated server accounts to protect hosting clients and to make it easier for them to grant secure access to third-parties. All users need to connect to the VPN is an OpenVPN client, many of which are available for free.

Posted in:
Magento, Security, WordPress

Source link

What’s Wrong With Security By Obscurity For WordPress?

What's Wrong With Security By Obscurity For WordPress?

Photo by iAmMrRob on Pixabay

We instinctively hide the things we find valuable. It makes sense: if thieves and other bad actors can’t find our valuables, how can they take them? In the digital age, we act on the same instinct. A common security precaution taken by WordPress site owners is to move the login page to a different location; if hackers can’t find the login page, they can’t launch a brute force attack against it. Hiding things, moving them, making it difficult to figure them out — these are examples of security by obscurity.

When I talk to WordPress hosting clients about security, the concept of security by obscurity comes up all the time. Among the common misconceptions I hear is the belief that owners of low-traffic sites don’t need to worry about security — their site is obscure, so it’s inherently secure. In fact, automated scanners regularly check through a large proportion of the web’s IP space looking for vulnerable sites. An insecure site is likely to be hacked even if it’s never had a single visitor. Criminals like sites with large audiences, but they also like any vulnerable site with storage and bandwidth.

An example of the application of security by obscurity from more sophisticated WordPress site owners is changing the default Administrator username because they know criminals will target it.

But there’s a problem with relying on security by obscurity: all it takes is for someone to find what you’re hiding and it’s game over. If your website has a security vulnerability, you might reason that because it’s difficult to find, there’s no point putting in the effort to fix it. If few people visit your site, why update it regularly; even if there is a vulnerability, who is going to be looking for it? If your site is a blog and there’s no obvious financial motive to compromise it, can’t you just cross your fingers and hope for the best?

Security by obscurity does nothing to fix the underlying problem. You might want to continue to use an abandoned WordPress plugin, but if you simply hope that no-one notices you’re using a vulnerable plugin, you’ve done nothing to mitigate the underlying issue. It’s a time-bomb that could go off at any moment.

But as renowned security expert Bruce Schneier points out, “security by obscurity sometimes works.” Security by obscurity isn’t bad per se, but it should be a small part of a site’s security processes. Deleting the “admin” user and choosing a less easily guessed username will make your site a little safer from automated attacks and attacks by inexperienced criminals, but implementing two-factor authentication solves the problem.

Moving your WordPress site’s login page to a non-standard location is likely to confuse bots and reduce the number of brute-force attacks your WordPress site has to cope with, but installing a rate limiting plugin will — for the most part — make life much more difficult for brute force attackers while preventing bots from consuming your site’s resources.

Security by obscurity should not be relied on to keep WordPress sites safe. It should be in the mix, but obscurity is no substitute for security best practices.

Posted in:
Security, WordPress

Source link

GitHub Introduces Security Alerts For JavaScript Projects

GitHub Introduces Security Alerts For JavaScript Projects

Photo by Brandon Green on Unsplash

GitHub’s has introduced Security Alerts for JavaScript and Ruby-based projects, with more languages coming soon. The alerts use GitHub’s dependency graph feature, which was introduced last month to provide a visual display of the dependency hierarchy of compatible projects.

JavaScript projects in particular tend to have lots of dependencies, and, until now, there has been no easy way to check for security vulnerabilities in individual dependencies — projects have to trust the software they depend on. As JavaScript becomes increasingly important to the WordPress ecosystem, a tool like this will make it easier to build safe integrations.

Open source projects build on the capabilities of other open source projects. WordPress, for example, depends on Linux, Apache, MySQL, and PHP, among many others — all open source projects that WordPress uses to provide functionality that would otherwise have to be re-created from scratch. The web wouldn’t be what it is today without the ability to reuse code in this way.

However, security vulnerabilities in software can put every user of that software at risk, including other projects that depend on it. The JavaScript ecosystem is massive, with tens of thousands of small modules, each of which might depend on other modules, which depend on other modules, and so on down the line.

As any JavaScript developer knows, even a simple project with a couple of dependencies installed with NPM (the Node Package Manager) can pull in hundreds of dependencies. How does a developer know there isn’t a security issue with one of those packages?

The truth is that they don’t know. They trust the system to find and fix vulnerabilities. Outside of strict government and corporate software projects, no one has the time or the money to check the security status of every library used by their software.

GitHub’s Security Alerts are an attempt to address this problem automatically. GitHub knows about the dependency graph (the tree of packages a project depends on) and can cross reference that information with vulnerability databases. GitHub’s Security Alerts use the National Vulnerability Database of the National Institute of Standards and Technology.

The feature is turned on by default for public repositories, and will email project administrators when a vulnerability is discovered. It can be turned on by administrators of private repositories if they so desire.

There are already projects that promise to do something similar to GitHub’s Security Alert for JavaScript, including the proprietary Snyk and the open source Audit.js project. But GitHub’s scale — many popular open source projects are hosted on GitHub — gives it an advantage. And although we’ve focused on JavaScript in this article because of the WordPress connection, GitHub is in a good position to roll out the same tool for many different languages, including, eventually PHP.

Posted in:
Security

Source link

Are WordPress Plugins Safe?

Are WordPress Plugins Safe?

Photo by Renatto Mora on Unsplash

Over the last couple of months, we’ve seen several incidents of previously trusted plugins being infected with malware by malicious developers. Plugin vulnerabilities are nothing new: developers make mistakes and those mistakes have consequences for security. But many of the recent attacks involved the deliberate introduction of malicious code.

Does that mean we can’t trust WordPress plugins? I’d advocate an approach of trust, but verify — and of making sure you keep yourself apprised of the potential risk.

Earlier this month, Wordfence reported that zero-day vulnerabilities in three popular plugins were being exploited to inject SEO spam into WordPress pages. The Display Widgets plugin was sold to a developer who added a backdoor that was also used to inject SEO spam.

Anyone who had installed these plugins from the official repository would have had their site infected. Attacks of this sort are known as supply-chain attacks. Rather than trying to compromise hundreds of thousands of sites, the attackers focus on software they know is installed on those sites. It’s easier to buy a plugin or compromise a download server than it is to attack the sites directly.

It’s worth emphasizing that this is a rare occurrence. Although a cluster of malicious plugins has been discovered in the last few weeks, it’s a problem that only affects a handful of the tens of thousands of free plugins available to WordPress users.

The WordPress Plugin Repository team has a challenging set of responsibilities: there are over 50,000 free WordPress plugins and it is next to impossible to monitor every one for malicious code. In spite of those obstacles, they do a fantastic job. Malicious plugins are quickly removed from the repository when vulnerabilities are discovered. Given the popularity of WordPress, it’s a testament to the team that this doesn’t happen more often.

But that’s not especially comforting to site owners whose WordPress sites start spewing spam. The sad truth is that any popular project will be targeted by criminals. There is always a risk and anyone running a website has to be aware of that risk.

What can site owners do to keep their sites safe? Regular updating is still the best protection against security risks. Without updates, nothing gets fixed. Beyond that, keep an eye on WordPress blogs that report on plugin security vulnerabilities. Among the best are:

Additionally, a Web Application Firewall (WAF) like those provided by the WordFence Security Plugin and the Sucuri Security Plugin can mitigate the risk even when a vulnerable plugin is installed.

The WordPress team is discussing solutions that integrate security warnings into the WordPress dashboard. There is currently no way to inform site owners when a plugin is removed from the repository for security reasons. Until that initiative yields a useful solution, WordPress site owners might want to take a look at Plugin Security Scanner, a plugin that scans for vulnerable plugins and emails the site owner.

Posted in:
Security, WordPress

Source link

Critical Vulnerability Breaks WiFi Security And Puts Hosting Clients At Risk

Critical Vulnerability Breaks WiFi Security And Puts Hosting Clients At Risk

Photo by rawpixel.com on Unsplash

A critical weakness in the protocol used to protect WiFi connections can be exploited to decrypt any data traveling between a WiFi client and the router it is connected to. Some variant of the Krack Attack vulnerability is present in nearly every WiFi device in the world. Unlike many vulnerabilities, this one isn’t the result of a bug in a specific implementation of the software, but a flaw in the WPA2 standard that developers base their implementations on.

The immediate consequence of the vulnerability to Krack Attacks is that WiFi networks cannot be trusted. Most of us are familiar with the idea that open WiFi networks we don’t control should be treated with suspicion — sending unencrypted sensitive data from a coffee shop isn’t a good idea. But the new vulnerability means that even WiFi networks we do control can’t be entirely trusted because of the flawed security protocol.

It’s not easy to exploit the vulnerability: the attackers have to be connected to the same WiFi network, but the risk is still significant.

It should be pointed out that WPA2 only handles data that travels between the client — a mobile device or laptop — and the wireless router. If data is also encrypted with a different protocol at a different level of the network stack, that encryption is unaffected. The flaw in WPA2 does not mean that people can intercept and decrypt information sent over SSL-secured connections.

Mitigating The Risk Of Krack Attacks

We expect fixes for routers and client devices and applications will be made available as soon as possible. As ever, updating your devices is the best way to mitigate the impact of this vulnerability.

As I’ve already noted, users of websites and eCommerce stores protected by SSL certificates have an additional layer of protection that will prevent an attacker from reading sensitive information even if they can decrypt the WPA2 connection.

All Magento stores should be protected by SSL certificates — payment gateway services use SSL by default, but without an SSL certificate for your Magento store, other sensitive information can be observed by an attacker. Responsible eCommerce merchants protect their customers with SSL certificates.

One scenario in which both Magento and WordPress site owners are at risk is when carrying out work on a site over an unencrypted connection: FTP is a common example. If an outside contractor or developer is working on your site from a WiFi network vulnerable to a Krack Attack, there’s nothing to protect sensitive data.

We offer OpenVPN virtual private networks for WordPress dedicated server and Magento dedicated server hosting clients to allow site and store owners to grant secure access to third-parties. Once logged in to an OpenVPN network, all communication is encrypted, protecting data even if it travels over a vulnerable WiFi network.

Learn More About Krack Attacks

Krack Attack stands for Key Reinstallation Attack, and it exploits a flaw in the 4-way handshake that takes place between a WiFi client and a router. When your device connects to a wireless router, a conversation between the devices sets up a shared encryption key that is used to encrypt subsequent traffic.

Krack Attacks trick WiFi clients into reinstalling a key that is known to the attacker. A key should only be able to be installed once: if an attacker can force the same key to be reinstalled, they can, along with other information collected from the network, decrypt the connection. You can see the full details of how this works on the Key Reinstallation Attacks website.

Posted in:
Magento, Security

Source link

What Is A Drive-By Download Attack?

WordPress Security Basics: What Is A Drive-By Download Attack?

Photo by Caleb George on Unsplash

In previous articles we’ve talked about why criminals are interested in attacking WordPress sites and some of the methods they use. Today we’re going to look at drive-by downloads, a common category of attack used by criminals to infect site visitors with malware. Drive-by downloads are software downloads made to a device without the permission or knowledge of its owner.

Most such attacks are carried out using the compromised content managements systems of legitimate sites, infecting the site’s visitors with malware that serves the interest of the attacker.

This June, security researchers at Sucuri noticed that a large number of WordPress sites were being used by criminals to infect web users with ransomware, so it’s worth going into some detail about how attacks of this sort work.

When an attacker compromises a WordPress site – usually because the site hasn’t been updated — they’re not necessarily interested in the resources of the site. Instead, they’re interested in the site’s audience. They want to use the site’s popularity to their own advantage, infecting its audience with ransomware, botnet software, software that steals banking and credit card details, and so on.

The first stage in a drive-by download attack is to find a vulnerable WordPress site and to compromise it. When the attackers have control of the site they inject code into its pages and JavaScript files. The exact nature of the code varies, but its basic task is to cause a visitor’s browser to download and execute code installed on a domain the attacker controls. This can be done with a simple redirect to the malicious site, an iFrame, or even an innocuous-looking advert.

The code the attacker wants to load is usually part of an exploit kit. Exploit kits like Nuclear and Angler are complex applications that probe the software on a visitor’s device for vulnerabilities, often in PDF reader and Flash player software. If the exploit kit finds a vulnerability, it compromises the visitor’s device and uploads a small piece of malware, which will typically download the main malware payload. The entire process can take place in less than a second and most people never notice that their device is now controlled by criminals.

So what can WordPress site owners do to minimize the chances that their sites will be compromised and used to infect visitors with malware? Most importantly, keep WordPress (and any other internet-facing software) up-to-date. It’s hard to overstate how important this is. If your site is not updated regularly, it’s almost certainly vulnerable. Themes and plugins should also be updated regularly.

While most WordPress sites are exploited because web hosting clients don’t update, a good number are hacked via simple brute-force attacks. Brute-force attacks only work if a site has easily guessed passwords, so the second most important mitigation advice is to use long, random, complex passwords. For extra safety, think about implementing two-factor authentication on your site.

Posted in:
Security, WordPress

Source link

How Do CAAs Make Your Sites Safer?

Certificate Authority Authorization Records Explained: How Do CAAs Make Your Sites Safer?

Photo by Anthony Martino on Unsplash

Certificate Authority Authorization records prevent SSL certificates being issued to hackers and online criminals for domains they don’t legitimately control.

When you ask a Certificate Authority to issue an SSL certificate for a domain, you have to prove that you control that domain. For Domain Validated certificates, that often involves uploading a special file to a server connected to the domain. If the file provided by the CA appears on the server, they know you’re in control.

In most cases, that’s a valid way to show who controls the domain. But, if a hacker compromised a WordPress or Magento site, they might be able to upload a verification file. There’s a flaw in the system that can be used by malicious individuals to influence a Certificate Authority to issue a certificate for a domain they don’t have legitmate control over. They have control over the site, but that control isn’t legitimate. Certificate Authority Authorization records are intended to close that loop in the verification process.

Certification Authority Authorization (CAA) records are a “new” (the RFC for the proposed standard was technically released in 2013) DNS record type, which will be used by Certificate Authorities (CAs) to add an additional layer of security for domain holders in regard to SSL certificates being provisioned under their name.

The CA/Browser forum – a voluntary group of companies such as Google, Mozilla, and Comodo – took a vote on making the use of these records mandatory, which passed earlier this year.

This means that major browsers will only trust certificates if they’re issued by a Certificate Authority that checks CAA records as part of its process. If the domain owner sets the CAA DNS record, Certificate Authorities have to respect the contents of that record.

How CAA Records Work

In order to help explain this better I’ve provided an example below:

We’ll presume Acme Company, Inc. controls example.com and only uses Comodo as their CA. The admins for their domain/DNS zone create the following CAA record:

example.com.       IN      CAA     0 issue "comodoca.com"

When the admins for example.com submit a request to Comodo to create a new SSL certificate for their domain, Comodo then runs a lookup against the domain’s existing CAA records to determine if they are permitted to issue the certificate. Upon seeing that the record exists and references them, they proceed with the creation of the certificate.

It’s worth noting that CAAs don’t take the place of current verification/validation procedures for SSL provisioning, but rather add an additional layer to cover situations that were not handled under the existing processes.

To dive into some specifics on how the records themselves are laid out, I’ve provided examples below for each “property tag” that can be specified:


issue

As shown above, the “issue” property tag specifies a specific CA that is authorized to provision certificates for the domain in question.

Example:

example.com.       IN      CAA     0 issue "comodoca.com"

issuewild

Exactly the same as issue, however this allows for wildcard certificates to be issued as well

Example:

example.com.       IN      CAA     0 issuewild "comodoca.com"

iodef

This property tag currently isn’t fully supported by all CAs, however its purpose is to provide further information such as E-Mail addresses, that can be used by CAs in situations where there’s an issue with the certificate itself or in cases where someone may have made an attempt to request a certificate be created that violates any other CAA record property tag rules.

Example:

example.com.       IN      CAA     0 iodef "mailto:[email protected]"

What Do CAAs Mean For Hostdedi Customers?

This is a good thing. There have been countless events in previous years in which malicious parties have been able to provision certificates for domains that they don’t have control over. This new enforcement tool provides companies and individuals with another layer of security for their domains and the certificates issued under them.

In addition to all of the above, CAs are only enforcing these rules if the records exist. If you’d rather not use them (though I’d highly recommend doing so) your interactions with CAs when purchasing a certificate will be the same as they always have.

We’re proud to announce that we’ve implemented full support for CAA records within Portal and you can log in and get started with creating those today.

As always, if you have any questions regarding these records or need assistance with creating them, you can contact the best Support Team in the world by opening a ticket, E-Mailing [email protected], or by contacting us via phone at any time.

Posted in:
Security, Webmaster

Source link

Deloitte’s Security Troubles Show Why Two-Factor Authentication Is So Important

Deloitte’s Security Troubles Show Why Two-Factor Authentication Is So Important

Photo by Ray Hennessy on Unsplash

For a business with more than a handful of employees, managing authentication credentials like passwords and usernames can be a huge headache, as Deloitte, a “Big Four” accountancy firm discovered this September. A protracted breach of Deloitte’s networks, which leaked emails and other sensitive information linked to some of the biggest corporations in the world, could have been avoided if Deloitte had protected user accounts with two-factor authentication.

Deloitte boasts revenue in excess of $37 billion and is one of the largest auditing and accountancy firms in the world. It is also a leading provider of cybersecurity services. It appears Deloitte’s networks were compromised when a hacker gained access to log-in credentials for an admin account. There’s some disagreement what was leaked, but Brian Krebs suggests a large amount of highly sensitive data was exfiltrated over many months.

It’s not known how the admin account was compromised, and there could be any number of explanations, from carelessness to brute-force attacks. But one thing is clear: two-factor authentication would almost certainly have prevented the attacker from gaining access, even if they had the admin user’s username and password.

Two-factor authentication uses an additional factor of authentication in combination with a username and password. The TFA most users are familiar with involves a one-time code being sent to a device in the user’s possession — their phone or a dedicated dongle. If the user can demonstrate that they know the number, it proves they have possession of the device. Passwords and usernames leak all the time, but it’s much less likely that an attacker would have access to the password, the username, and a trusted user’s unlocked phone at the same time.

Authentication leaks are among the most dangerous security breaches because they’re so hard to spot. There are few tell-tale signs: it looks as if an authentic user has logged in. In the Deloitte case, it seems the attackers were able to access the network from the fall of 2016 until this March.

eCommerce stores and web sites can more easily be compromised if retailers and publishers make the same mistake one of biggest cybersecurity consultancies in the world made by trusting people to manage passwords properly.

Passwords are a strong form of authentication if they are managed intelligently. Long and random passwords used as part of a well-designed authentication system are next-to-impossible to discover. But most people, including developers and others you’d expect to understand the problem, don’t choose or manage passwords properly. Two-factor authentication provides a second layer of security that can keep a Magento store or WordPress site secure even if a user is careless with their password.

Magento retailers should take a look at Sentry, a Magento two-factor authentication plugin Hostdedi developed in partnership with Human Element. Sentry works with the Google Authenticator and Duo Security services to provide easy-to-use TFA for Magento eCommerce stores. WordPress user should consider WordPress Two-Factor Authentication.

Posted in:
Security

Source link