Rev Up Web Security with Two-Factor Authentication

Guard your site against online criminals

In “Secure Your Web Application’s I/O” (InstantDoc ID 25227), I discussed methods for securing your Web applications from a design and programming standpoint. Now, it’s time to take a look at securing your users' experience—specifically, through the logon mechanism. Gone is the day when you could simply create an .htaccess file and just use the built-in, basic authentication mechanism in HTML, which was easy and simple but incredibly unsecure. The rise in quantity and sophistication of phishing, social engineering, identity theft, and other online fraud attacks make passwords alone an ineffective security measure for most online transactions, particularly those that recur and involve access to personal financial information. It's one thing for someone to gain access to your Amazon or free email account; it's another thing entirely for someone to crack your online banking account.

High-profile breaches in security at large institutions have raised public and governmental awareness of the increasing threat of this kind of crime. Many industries, especially regulated ones, are beginning to require two-factor authentication for their Web applications. The banking industry has been hit hard. Online criminals go after banks for the same reasons offline criminals do: Banks have money. In a recent letter (, the Federal Financial Institution Examination Council (FFIEC)—the governing board for most banks—laid out guidance requiring banks to implement two-factor authentication in their online banking applications.

Your bank might have already contacted you about these changes, and maybe you're using the new methods now. If not, rest assured that you will—this “guidance” requires banks to have two-factor authentication in their online services by 2007. Other sectors (e.g., government, health care, legal), in which large amounts of personal data are exchanged over the Web, are sure to follow. So, what exactly is two-factor authentication, and how can you provide this protection for your Web applications? Let's explore the technology and some of the solutions that are available today.

Getting to Know It

In his article "Authentication Options" (InstantDoc ID 50550), John Howie discussed the differences between single-factor and two-factor authentication, so I wont belabor the point. Simply put, requiring a logon/password combination is called single-factor authentication, whereas two-factor authentication uses two ways to authenticate you—typically, the logon/password combination coupled with either something you have (e.g., token, key card, digital certificate) or something you are (e.g., biometric data such as a fingerprint or iris scan).

You can support both two-factor components through the use of hardware devices such as token readers and biometric devices. The costs of such items have come down precipitously in the past few years; USB token-style devices are incredibly cheap in volume, and many manufacturers offer laptops with built-in fingerprint authentication. These devices deliver information (typically in the form of a digital certificate or biometric data) that further authorizes users. Two-token authentication greatly deters hacking because of the difficulty of cracking such devices. However, implementing the technology isn’t as easy as merely buying a bunch of USB key fobs and certificates. If you want to integrate this kind of authentication into your site, you'll have to accomplish a great deal of back-end programming, although Microsoft has simplified matters by building two-factor support into Windows XP and later OSs. So, there are still costs to endure, but they're not nearly what they used to be.

However, there's still the problem of user training and support. In large-scale implementations, such as an online banking system at a large national institution, measures that count on pieces of hardware have many challenges. Imagine trying to support millions of USB devices for online banking customers, many of whom are online for the first time. (Try helping grandma find the USB port on her computer, assuming she isn’t using a pre–Windows 98 computer with no USB ports.) Also, you have the problem of token loss and the infrastructure necessary to replace them. You can see that biometric or token authentication is most appropriate for corporate deployments to secure intranets or extranets in which users are reasonably computer-savvy and part of a manageable population.

What's Available?

For larger deployments that involve consumer populations, simpler is better; the less the user has to do, the better. In the Harvard University and UC Berkley study "Why Phishing Works"? (, the authors found that although users wanted more security in their online applications, they didn’t want to have to do anything different or add any kind of perceived hassle to their experience. Some organizations have looked to a form of two-factor authentication that provides a higher level of security without the need for hardware devices. Several companies have sprung up to supply such software-only solutions. There are several different approaches offered to meet this demand and a few of the major vendors are listed below.

Geo-localization. One authentication method is to geo-localize users—that is, study the user's originating IP address or other network-based data. This method is based on the notion that users log on from the same location most of the time. Depending on the granularity of the control, this kind of authentication accepts logons from only a certain area, a certain phone central office, a certain ISP (people don’t switch ISPs often), or other IP-based criteria. For example, let’s say a user normally logs on from his or her home on the Time Warner cable service in the New York City area. If a connection attempt came instead from the Ukraine, the software would see it as a highly suspect attempt and either block it or pose some test questions to ensure that the user is legitimate. This information is easy to look up; there are commercial databases of updated IP address localities maintained just for this purpose. The biggest benefit is that this method can occur in the background, unknown to the user, and provides two-factor authentication via something the user has (logon/password combination) and something the user is (location via IP address). However, this method alone is subject to attack, including IP address spoofing or a malicious user attempting to hack the account from the immediate area. Also, if the logon fails the initial attempt, allowing authentication based on test questions is subject to all the weaknesses of single-factor authentication. An address or a mother’s maiden name is probably information that a good phisher already has (or can obtain through additional phishing attempts). Because of these weaknesses, I don’t recommend this option alone for high-security applications or regulated industries. However, it can be a decent “poor man’s” upgrade from single-factor authentication. It’s inexpensive to develop in house and easy to deploy to users. A company’s HR Web site is one example of an appropriate application of this method.

Behavioral model. Another approach relies on a behavioral model. This method focuses on a user’s activities after he or she logs on, requiring higher levels of authentication when the user needs to perform certain risky tasks. One solution that uses this method is Entrust’s IdentityGuard. The technology doesn’t authenticate the user deeply at the front door but rather uses a system of fraud scoring, based on the user’s activity once he or she is in. Certain actions or requests might then trigger a request for additional authentication, which can be in the form of challenge questions, a phone call, or an outright denial of the transaction request. If a user typically logs on only once per month, then is suddenly logging on several times per day, the software will probably flag that user. The designer of the system can choose to limit access or use test questions to further authenticate the user. This model closely follows that of the credit-card industry, which has a well developed system for tracking fraud and escalating interdiction based on a mature database of user behavior. Entrust also offers integration with tokens and biometric controls for stronger two-factor authentication up front.

One of the weaknesses of this approach is that it takes time for the program to build up enough logons and user activity to be able to accurately predict fraudulent behavior. Also, a customer who tends to be highly erratic or is a frequent user of many of the system’s functions would be less protected than one who isn’t very active. This approach also suffers from the same flaw as the previous system: Even with an initial authentication failure, a malicious user could potentially gain access if he or she knew answers to challenge questions.

Challenge images. Another type of Web-based two-factor authentication is challenge images. Passmark Security’s Passmark system is an example of this approach. In this implementation, favored by Bank of America, customers choose an image and a title. When logging on from a preauthorized computer, the customer's valid Sitekey appears. If this image doesn’t appear, the customer isn’t at the official bank site. As long as it does, the customer enters his or her password and the system begins the logon process. If the customer logs on from somewhere other than his or her usual site, the system asks one of three challenge questions before displaying the Sitekey. A benefit of this method is that a keystroke logger can't sniff the Sitekey because it's an image file. Another beneficial aspect is that this method performs mutual authentication—that is, Web site authentication occurs in tandem with customer authentication.

This system isn’t really true two-factor authentication, rather, it's a hybrid method that uses one-factor authentication twice. It's still vulnerable to phishing. For example, a malicious user masquerading as a technician might call or email a customer, asking for image verification. There are other ways around this method, such as the broken-link trick: By displaying a broken-link graphic instead of the image, the phisher hopes the customer will assume the image link is broken because of an Internet problem and proceed with the logon. A surprising number of people fall for this trick in tests. Putting the onus on the customer to verify the image and to remember yet another thing is depending on a weak link that phishers can take advantage of.

Green Armor Solutions takes a slightly different approach to this method with its IdentityCue technology, which uses visual cues created from hashes of the password and logon ID. These cues help to authenticate the system to the user without the predictability of image files. The cues also use a combination of secure cookies and heuristic data (e.g., browser version, time zone) from the Web session to further authenticate the user. This method eliminates some of the downsides of pure image-based authentication systems while providing a fairly strong link to the actual user that doesn’t rely on challenge questions, which can reveal additional personal information to a skilled hacker.

More to Come

These are just a few of the many solutions on the market, and surely new methods will evolve along with the technology itself. Each method has its pros and cons, and none of them is perfect. However, adding two-factor authentication to your Web site can be an extremely valuable security upgrade. In some cases, federal, state, or local regulations might even demand the upgrade. Two-factor authentication raises the bar for potential hackers and phishers, and will greatly protect you from the onslaught of online criminals. If your Web site is better protected, most fraudsters will simply move on to an easier mark.

However, before you make the plunge, you need to consider the costs, the ease of implementation, and the effect on your users. You don’t want to make it so hard to get in that you discourage Web use and cause users to fall back on more costly information sources (e.g., toll-free numbers, teller lines). After all, the most secure Web site in the world is one that’s never used.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.