Home-Grown Two-Factor Authentication

 Executive Summary:

Various commercial solutions can provide protection for your Web sites beyond traditional authentication, which uses one factor (i.e., the logon ID and password combo). Second-factor solutions use geo-localization, user behavior, challenge images, and perhaps the more familiar smart cards, tokens, and fingerprints. (For more information about commercial second-factor solutions, see the articles in the Learning Path box.)

But commercial solutions aren't your only option. You could also craft a “home grown” two-factor authentication solution. Let's explore some ideas for coding your own two-factor solutions for your Web applications, and look at some code examples that will get you started down the right track.

Two-Factor in Review
Let's jump back for a quick review of two-factor authentication—that is, using two different forms of identification to authenticate potential users. Generally, an authentication attempt can take any of three forms:

Most applications use only one of these forms, usually the first one. Your logon ID and password constitutes something you know.

Most Web sites and applications are fine with this level of security. However, with the rising tide of identity theft and other forms of online fraud, some Web sites are starting to require two-factor authentication to gain access. Starting this year, all online banking sites should be using two-factor as required by new regulations. Other applications that might soon be required to use two-factor are HR sites, medical sites, government sites, and any other application that might expose someone’s personal data.

As mentioned above, many commercial applications for two-factor authentication are available. The cost is all across the board, although it starts rather high. Perhaps you don’t have the budget for a big box solution. Or maybe your code is so customized that it won’t work well with the available solutions. If you either can’t or won’t use an off-the-shelf application, you'll have to think about implementing two-factor with your own solution. Here are some ideas to start you in the right direction with your development efforts.

Building on the IP Address
"Rev Up Web Security with Two-Factor Authentication" (http://www.securityprovip.com/article/articleid/95117) has a brief discussion of using someone's IP address to further authenticate him or her. This would fall under the category of something you are. Many commercial solutions tend to implement something you are with biometrics (e.g., a fingerprint or iris scan). Decreasing hardware costs and improved software support have made this option much more accessible, but prices are still fairly high, and logistics (e.g., distribution of fingerprint readers) can be daunting.

Also, knowing that you're going to store biometric data does make some users a bit nervous. It’s one thing to have someone steal your Social Security Number. It’s entirely another to have a fingerprint "lifted"!

Using a solution entirely based in code might be easier and less costly. Granted, it’s not as definitive as physical solutions, but for many applications, it provides an adequate level of certainty. Every user has an IP address, and it can be used as a second factor of authentication.

In a nutshell, when users attempt to log on, you obtain their IP address from Web server logs or some other mechanism. Then you put the address to one or more tests. If it passes, and if the user's logon ID and password check out, you grant the user access. If the user doesn't pass this level of inspection, you either reject the request or go to a deeper level of authentication. This could be in the form of asking users additional questions about their identity (e.g., mother’s maiden name) or referring them to a phone representative for offline verification.

There are a few ways to test IP addresses, each one providing a different degree of certainty that users are who they say they are. The easiest test is to simply compare a user's IP address to a list of known bad addresses outside your service area. For example, if your users are mostly in the United States, you could test against a list of non-US bad addresses. Given that a large portion of ID theft originates outside the US, blocking non-US bad addresses will certainly eliminate a high number of illicit attempts.

Bad-address lists are readily available. Bob's Block List at http://www.unixhub.com/block.html begins with blocks of Asian and Latin American/Caribbean addresses that you could test against if you don't have users in those regions. Please note that lists from free sites will require some editing to make sure you don’t block good sites. Commercial lists are available that are more accurate, such as MaxMind at http://www.maxmind.com. Listing 1 shows some sample pseudocode for this approach.

However, if you don't want to block users by region or you need to be more exacting, you can record a user's IP address the first time he or she registers, assuming that the registration process includes a means of verifying that the user is valid. You might have the user answer one or two questions (such as the name of his or her high school) or ask the user to enter a registration code that you've sent him or her via email. Once you have the IP address (and the verification), you can use the address to validate future logon attempts.

If the users are all going to be coming from your corporate sites with known and fixed IP addresses, checking their addresses against a list of pre-approved addresses works great and keeps users from unknown sites from logging on. However, if users will be accessing the application from sites where the addresses aren’t known beforehand—say, from home connections, which typically don't have a static IP address—you can’t be quite as precise.

The less accurate solution is to match “fuzzified” IP addresses. Home users' ISPs assign IP addresses within a range that they own, generally a Class C or Class B subnet. So you can use just the first two or three octets of the IP address for authentication. For example, if the address you register for a user is 192.168.1.1, you might subsequently accept an address from 192.168.1.1 to 192.168.254.254 for that user. Although this approach allows some exposure from attackers that use that same ISP, it narrows the window considerably.

You can also verify users by using their IP address to locate them geographically. You'd need to purchase a commercial database that contains all the known IP ranges and their approximate location from a company such as MaxMind or Geobytes (http://www.geobytes.com). If you register a user's location as Houston, when that user subsequently attempts to log on from Romania or even New York, you would know to block the attempt or at least escalate the scrutiny of the logon attempt. This technique addresses the problem of an ISP changing its address block. However, it still allows someone to attempt an unauthorized logon from a location in which you have registered users.

You could also do a double second-factor authentication, starting with weeding out all IP addresses that match a banned list or checking against a “good" list. If you use the good list approach and an IP address isn't on the list, the code could ask the user verification questions. If the IP is finally approved, the code could ask the user whether to add the current IP to the good list (users should be trained to say no if they're currently using a remote computer that they won't use regularly). Listing 2 shows how you might do the banned or OK check, again using pseudocode.

One situation that can trip up IP-address-based authentication is a large base of mobile users who log in from hotel rooms or other sites in the US and abroad and constantly change IP addresses, ISPs, and locations. The banned IP list approach won't work for these users. The users won't be on your list of good IP addresses either. However, the users would still have to use the test question to authenticate.

If you wanted to provide a higher level of protection for traveling users, you could go deeper with your authentication and look at identifiers such as users' browser version (which doesn’t tend to change very often), their OS version, or even their network card's media access control (MAC) address. However, these methods would probably require running some kind of applet on the client to access those settings. Of course, MAC addresses and browser and OS versions can be spoofed, so this isn’t a perfectly secure method.

Using Cookies or Certificates
A different tack to take in our quest to authenticate is to ask for something the user has, one of the other two forms of authentication. Hardware-based systems ask for a token or something similar. A software-based system that you develop could use a cookie or certificate stored on users’ computers to verify that they are who they say they are. This approach is similar to the way secure certificates assure you that you're really submitting your order information to the right site when you do business with e-commerce Web sites.

Cookies are the easiest to implement. In fact, you're probably already using these to keep track of session keys and other information for your users. You would simply create a persistent cookie that would be saved on a user's computer so that you could ask for it at a later date to further authenticate the user. You could go beyond simple cookies and encrypt part of the cookie so that it couldn’t be easily recreated by an imposter.

If you wanted to provide a higher level of security, you could ask for a digital certificate. This would involve some preparation on the user’s part, either generating the certificate internally or getting one from a Certificate Authority (CA). The latter is the more secure method because faking a certificate issued by a CA is more difficult. However, the ongoing cost of maintaining the certificate might be on par with a two-factor solution that uses tokens or other hardware devices.

Of course, cookies and certificates would work only on users' home computers or other computers they have registered with your authentication system. You would have to have an alternate method of authenticating users on a computer they don’t own (e.g., public access computer, airport kiosk). The authentication questions described above and in Listing 2 are one method of doing this. However, you might consider whether you want users accessing your secure application from public access computers with all the risks of keystroke loggers, spyware, and so on that they pose.

You've now seen two ways to implement a simple two-factor authentication scheme for your Web applications: one using something you are (the IP address) and one using something you have (cookies or certificates). Keep in mind that these solutions aren't intended for very high security applications such as finance or regulated industries, for which hardware-based solutions might be more appropriate. But these solutions will work great in conjunction with other methods for providing a higher level of authentication in various intranet and e-commerce applications.