original

Multi-factor Authentication Is Simple Enough Now That Everyone Should Be Using It

Multi-factor Authentication (also sometimes called Two-Factor authentication) is a method provided by many sites and services to help their users better secure access to their accounts.  For the remainder of this post, I’ll use MFA for short.

Most major web services now offer some sort of MFA, and over the last several years, integrating the use of MFA in to your daily life has become simple enough that it should be accessible to most every user.

So much of our lives is online these days, that most of us have a lot of personal, private information stored with our email service providers, in our Dropbox folder, Google Drive, SkyDrive, etc.  Imagine if someone had the password to your email account.   What types of information might they be able to find out about you?  If it doesn’t give you a little cause for concern it should.   Yet for many people, those sites and services are protected only with a password – one of the weakest forms of security available to end users.

Even if you have good personal security habits, and make use of strong passwords that are regularly changed and never written down, it is still possible to pretty easily circumvent that security measure with the right tools, a little time, and a lot of persistence.  Unfortunately, the vast majority of users don’t have good personal security habits.

According to a study conducted by Time Magazine in January 2014, the most popular passwords that people selected to protect their information online were “123456”, “iloveyou”, and “qwerty”.  Ahem…..

Needless to say, those passwords aren’t indicative of good personal security habits at all. It’s roughly akin to leaving your wallet laying on the drivers seat of your car in plain view, with the window rolled up and the car door locked. Yes, you’ve put forth a minimal amount of effort to protect yourself, but it’s not going to discourage someone who is even marginally determined.

Are you responsible with maintaining security of the network in a workplace?  If so, the risk is even greater for you. According to a 2013 Verizon Data Breach Investigations report, 76% of network intrusions exploited weak or stolen login credentials.  In these incidences, the companies suffering the breach weren’t even really trying to make it difficult for their networks to be exploited. The tools needed to exploit passwords like “123456” aren’t sophisticated, and can be downloaded and run for free by anyone, of any age, with access to a working internet connection.

A good password should be your first line of defense in protecting your or your organizational data.  Sometimes the password policies of organizations work against themselves by requiring things like uppercase letters, special characters, etc.  If you haven’t see the classic xkcd comic about password strength it’s worth taking a look.

The point of the xkcd comic is that in most cases, a random string of words that can be remembered easily by the user is a much better strategy against a brute force attack than the typical password gymnastics required by most organizations attempting to enforce strong password policies that may encourage users to write down their passwords and stick them to the front of the monitor.

Fortunately, in addition to having a good, difficult to guess, password, multi-factor authentication adds another significant layer of protection by combining something the user knows (a password), with something the user has (a token, often sent to a phone via SMS or through a MFA application like Google Authenticator).

The way it works is pretty straightforward. You will download an application on your phone, and pair that application with a site or service that supports MFA. Typically, the site will provide you with a QR code that you can simply scan with your phone, and the pairing will happen transparently to the user.  Once activated, when you attempt to login to that service the next time, you’ll first be asked for your password. After successfully authenticating, you’ll be asked for a security code. You will open the authenticator app on your phone, copy the randomly generated code, and provide it to the login page to complete the login process. In most cases, this randomly generated code will be automatically changed every 20-30 seconds. The entire process adds a total of 10-15 seconds to the login process, but astronomically raises the security of your accounts.

A simple example can be seen below.  In this example, I’m logging in to my RSS feed reading application using my Google account.  Note that after entering the correct password, I’m challenged for a code that I can obtain by switching over to my authenticator application.  I copy the code, switch back to the application I was logging in to, provide the code, and complete the login process. It’s a minor additional step for a major security advantage.

134


authyMost authenticator applications will allow you to register more than one service, so that you go to the same code generator application for all your MFA sites.  My personal preference, and recommendation, is Authy, a great MFA application available for both iOS and Android devices.  Authy allows you to register multiple MFA accounts, and easily switch between them via a familiar interface.

If you’re interested in enabling MFA for the applications that you use regularly, be sure to check the support site for the service in question. Chances are they offer some sort of MFA. If not, don’t be afraid to request that they add this option. In 2014, this really should be part of the basic service offering for any serious provider.

Here are links to the MFA options offered by some of the services that I (and probably you) use regularly.

Twitter and Apple also offer their own implementations of MFA that work in slightly different ways. In the case of Twitter, the code is sent to your phone either via SMS (my preference) or through the Twitter application itself as a message sent directly to you in-app.  For your Apple ID, a four digit pin is sent via SMS to a registered device, and required in addition to your Apple ID password. To enable 2 factor authentication on your Apple ID, sign in at appleid.apple.com, and visit “Two Step Verification” under “Password and Security”.

In summary, if you haven’t already been exposed to the concept of multi-factor authentication, the good news is that it’s now very simple and convenient to use. Hopefully the information provided here will help you make yourself more safe and secure online. Good luck!

 

 

 

Share

Read More

Automatically insert Google Analytics tracking code as an outbound IIS rule

Google-Analytics-Crunchify-TrackEvents

Google Analytics is a wonderful tool for tracking the behavior of visitors to a web site, but one of the things that has always been challenging for site administrators is finding a way to embed the javascript necessary to track visits via Google Analytics in to every page on a web server.  Google recommends strategies like providing server-side includes with the code embedded – but that will only work if every site on a server is using the same programming language or else is able to make use of the same set of server-side include files.  Often, that’s not the case.

If you’re running IIS 7 or later, you can now easily take care of Google Analytics code inclusion by creating an outbound rewrite rule via the web server. This outbound rule can make sure that the Google Analytics code gets injected on the response from your server to any requests.  This is helpful in a couple of ways.  When new sites or content is created, there’s no need to worry about modifying the sites or code itself to include Google Analytics. Additionally, because the script injection is handled as an outbound rule, it isn’t going to matter if the site being visited is .NET, PHP, or simply HTML – the web server include the tracking code regardless.

Setting Up the Rule

Step_One-3Setting up an outbound Google Analytics rule is pretty easy – but there are a couple of things to watch out for that we’ll talk about in just a moment.  First, let’s quickly step through setting up the rule.

As a first step, open up IIS Manager, and in the connections window, highlight the site that you wish to create a rule for.  Once highlighted, the features for that site should appear in the right hand side of your IIS Manager window.  In the features section, double-click on the feature labeled “URL Rewrite”.

In the “Actions” pane, click “Add Rule”, and a modal window will launch allowing you to define the type of rule that you want to create.  In this instance, we want to create an outbound rule using the blank outbound rule template found in the modal window.MUWWW03

 

  1. Give the outbound rule a recognizable name
  2. In the “Precondition” drop down menu, choose “Create a new precondition”
  3. Define the precondition using regular expressions, and add the variable {RESPONSE_CONTENT_TYPE} as the input, selecting “Matches the Pattern”, and then adding the value “^text/html” as the pattern to match.
  4. After saving your precondition, verify that the name you gave it is listed in the drop down list of the “Precondition” section of the rule that you’re creating.  If not, select it before continuing.
  5. In the “Match” section of rule definition, choose “Response” as the matching scope.  Leave “Match the content within” blank, and in the “Content” drop down, choose “Matches the Pattern” using “Exact Match”.
  6. In the “Pattern” section, enter “</head”>, and choose the “Ignore case” check box.
  7. Leave the “Conditions” section blank, and move on to the “Rewrite” section.
  8. Select “Rewrite” as the action type, and in the value, past the Google Analytics tracking code.   Make sure that “Stop processing of subsequent rules” is left unchecked – and save your rule.

Prepping the Tracking Code

There are just a couple of things that you’ll want to do to prepare the Google Analytics tracking code so that you can use it as a URL Rewrite rule within IIS.

First, paste the entire block of tracking code in to a text editor (I recommend BBEdit for Mac users or Sublime Text for Mac or Windows users) and remove any carriage returns/line breaks, leaving yourself with the entire block of tracking code from <script> to </script> on a single line.

Next, at the end of this single line, append </head> so that when the rule removes the initial </head> tag and injects the tracking code instead, the </head> code is replaced after injection.

Finally, as a last step, IIS has trouble interpreting left curly braces as a part of URL Rewrite rule syntax.  The Google Analytics tracking code uses the left curly brace by default in almost all of its iterations – so you’ll need to manually inspect the tracking code in your text editor, and replace any instance of “{” with “{UrlDecode:%7B}”.

Testing the Rule

Once you’ve finished with rule creation, click “Apply” and then check to make sure that the code is being correctly included by requesting a page on your site in a web browser.  When the page is returned, view the source of the page and make sure that the tracking code is being included in the appropriate location.

Watch Out For

  • If you find after creating the rule that you’re encountering a javascript error message along the lines of “Uncaught SyntaxError: Unexpected token….” then you’ve likely missed a left curly brace in the tracking code in your rule.  Go back and make sure that any reference to left curly braces are URLDecoded as noted in “Prepping the Tracking Code”.
  • If you run pages that make use of Adobe’s ColdFusion server, note that ColdFusion compresses outbound content, and IIS outbound rules will not work if the response is compressed since the response won’t be readable by the rule definitions. This will cause a 500 Server error on ColdFusion pages.  The best solutions I’ve been able to come up with for these sites is to disable the outbound rule on ColdFusion based sites and instead include the tracking code manually for those sites in an include file. If someone knows of a better way to solve the issue with ColdFusion pages, please let me know in the comments.

 

 

Share

Read More

Defending against WordPress brute-force attacks using built in features of IIS

Throughout the past week, a very large network of compromised computers has been pounding away at sites using the WordPress content management platform, attempting to access those sites by continually attempting logins using default WordPress usernames, along with a combination of passwords.

For these attacks to work, the attacking machines have to continually try various combinations of passwords, throwing request after request at your system, until they find a combination that works.

One of the best ways to defend against such an attack is to make sure that you’re not using default usernames.  Even if you’re doing that, though, it doesn’t prevent the attackers from throwing posts at your WordPress points of entry.  This forces WordPress to have to process these attempted logins before determining that the username is invalid.

While there’s no major security vulnerability, when attackers are throwing post after post at your installation, it can hamper performance dramatically.

There’s plenty of advice online for people who’ve installed WordPress using an Apache web server, but not as much for people using IIS. Fortunately, IIS has some features that can help mitigate the problem.

Dynamic IP Restrictions

A great first line of defense is available by installing the Dynamic IP Restrictions extension (link).

Once installed, you’ll can configure your site to deny requests from any IP address that is sending too many requests to your server too quickly, based on the criteria you define in the configuration.

 

 

 

Screenshot_4_18_13_3_53_PM

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Inbound Rewrite Rule

Another great idea is placing a rewrite rule on your wp-login.php file that checks for certain conditions prior to processing a user login.  When a bot attempts to login to your site using an automated routine, you will usually see a post of attempted credentials directly to your wp-login.php file.  This allows for rapid automation of multiple login attempts.

This looks different than someone actually visiting your WordPress admin, and clicking the “Login” button after supplying credentials.  Specifically, when a post is coming directly from a bot, the header sent along with the post will be usually be missing the HTTP_REFERER header.  Knowing this can help you construct a rewrite rule that will prevent these attempted logins from being processed.

In Features view, click on the “URL Rewrite” icon, and click “Add Rule” in the Actions pane on the right.

Give your rule a name, and in the Requested URL drop down, choose “Matches the Pattern”. Choose “Wildcard” under “Using”.

In the pattern box, enter *wp-login.php*.  This pattern allows you to also catch any redirects caused by someone visiting a site at the /wp-admin/ URL.

Under “Conditions” choose “Match All”, and add the following two conditions:

1. {HTTP_REFERER} Does Not Match the Pattern *wp-login.php*

2. {REQUEST_METHOD} Matches the Pattern POST

Under “Action”, choose “Abort Request”

This rule should catch any automated attempt to post directly to wp-login.php, and stop the request before WordPress actually attempts to process it, allowing for improved performance.

Share

Read More