Emergence of Risk-Based Authentication in Online Financial Services: You Can't Hide Your Lyin' IPs

George Tubin
Senior Analyst

May 2005 Reference # V43:15N

TowerGroup Take-Aways Because the consumer desktop is highly vulnerable to malware attacks, TowerGroup urges banks to recognize the fact that consumers' credentials will become increasingly compromised over the Internet as well as other channels. Currently, the most (and perhaps only) effective means of protection that financial institutions can deploy against malware attacks is stronger authentication technology. TowerGroup defines "risk-based authentication" as an approach that uses both requested and observed customer information, along with data supplied during Internet communications, to assess the probability a customer interaction is authentic. In general, financial institutions have been hesitant to deploy hardware-based authentication devices because of the (actual and perceived) costs and complexities involved as well as the fear of consumer reluctance. Fortunately for the industry, the emergence of risk-based authentication technology provides a cost-effective, low-impact approach to strengthen online authentication without the need for hardware-based authentication devices.

Report Coverage TowerGroup has urged the financial services industry to adopt stronger authentication technology for online banking as well as other online financial services. However, most financial institutions understandably remain hesitant because of the high costs and customer inconvenience generally associated with hardware token devices. Fortunately, and not a moment too soon, a unique and innovative approach for stronger online authentication has emerged. This approach, known as riskbased authentication, is virtually invisible to end users, costs a fraction of the typical hardware authentication device implementation, and is quite effective to boot. This TowerGroup Research Note explains risk-based authentication, describes how it works, and identifies the vendors that supply risk-based authentication solutions to banks. Background With each passing day, those who are closely involved with online banking and e-commerce in general become more concerned about the growing issue of online fraud. The rise of phishing during 2004 was a wakeup call to the financial services industry to realize that criminals are clever and will continually develop new schemes for committing online fraud. Fortunately, the industry reacted swiftly and effectively and contained the phishing threat before it spiraled out of control. Today, most large banks have programs, processes, and technology in place that are reasonably effective at preventing, detecting, halting, and recovering from phishing attacks. See TowerGroup Research Notes V41:10PCN, A Phish Tale? Moving from Hype to Reality, and V41:11PCN, No Phishing Zone: Vendor and Industry Initiatives to Curb E-Mail Fraud, for a more detailed examination of phishing and approaches used to combat this problem.

2002 - 2005 The Tower Group, Inc. May not be reproduced by any means without express permission. All rights reserved. TowerGroup is a wholly owned subsidiary of MasterCard International and operates as a separate business entity with complete editorial independence.

However, as was laid out in TowerGroup Research Note V42:27N, The Sky Is Falling: The Need for Stronger Consumer Online Banking Authentication, a more ominous cloud looms. The impending threat of more advanced malware attacks that secretly install computer code developed for the malicious intention of collecting various user information continues to weigh heavily on banking executives. The compromised information can be used to steal funds from a user's bank account or commit identity theft. And it makes sense for criminals to focus on stealing a user's online banking credentials because the username and password combination is relatively easy to acquire and then relatively easy to use to fraudulently access an online banking account and commit other financial fraud. Exhibit 1 depicts the increasing frequency of malware attacks and future growth trends.

Exhibit 1 Worldwide Malware Attacks on the Internet (1999-2006) Source: McAfee

Knowing that criminals will become increasingly more effective at stealing users' online banking credentials, we must develop approaches that require more than the simple username and password to access an online banking account. While we continue to wait for better techniques to protect PCs against these attacks, we must develop approaches that make stolen customer credentials useless to the online criminal. Currently, the most (and perhaps only) effective means of protection that financial institutions can deploy against such malware attacks is stronger authentication technology. As discussed in TowerGroup Research Note V42:27N, The Sky Is Falling: The Need for Stronger Consumer Online Banking Authentication, a variety of stronger authentication approaches exist to strengthen the security of online access. The bottom line (and this cannot be overstated) is that we have to assume that username and password information will become increasingly compromised. Therefore, the industry must implement authentication schemes that are not reliant solely on the username and password combination.

2002 - 2005 The Tower Group, Inc. May not be reproduced by any means without express permission. All rights reserved.

Most of the available approaches to multifactor authentication require a hardware device to supplement the traditional username and password. The device could be a password token, biometric reader, smart card, cellular phone, or any number of authentication appliances. The device adds another authentication factor, something the user possesses, beyond the simple username and password information (representing something the user knows). While these devices are generally effective for strengthening authentication, they are costly to implement and manage, are vulnerable to session hijacking and "man-in-the-middle" attacks, and may be rejected by the bank's convenience-oriented consumer base. Still, because these devices vastly improve the security of online authentication, many institutions are considering them for their consumer online banking customers. In general, financial institutions have been hesitant to deploy hardware-based authentication devices because of the (actual and perceived) costs and complexities involved as well as the fear of consumer reluctance. Making a hardware authentication device an option for a bank's customers would involve implementation and management complexities similar to those of a full implementation of these devices and may not stimulate the desired adoption levels. Most financial institutions will not require mandatory use of hardware devices for fear of mass customer defection. Other intriguing approaches to stronger online authentication have been developed and are being evaluated by financial institutions. For example, Real User developed an approach to online authentication called PassFaces, which essentially requires users to remember a set of face images. Upon authentication, the user is presented with a set of nine face images and is required to select the one face that is in the previously assigned set. This selection process is repeated several times to ensure that the user is not simply guessing the correct face. Real User argues that face images are much easier to remember, and much harder to steal or phish, than alphanumeric passwords. Another interesting solution, IdentityGuard, developed by Entrust, Inc., provides users with a card that contains a small grid (think Excel spreadsheet) containing assorted characters within each cell. During authentication, the user is presented with several grid coordinates (e.g., A5, D3, E1, and I3) and asked to type in the character on the card that corresponds to each coordinate. This approach ensures that the user is in possession of a second physical authentication factor but costs a fraction of the price of other hardware token solutions. Both the Real User and Entrust solutions provide better security than the simple username and password approach but are not panaceas. While the application cost for these solutions would be lower than that for hardware-based token devices, costs for the technology implementation and management, internal and external education, and ongoing support are similar. And the solutions require end users to learn and adopt a new authentication approach. If at all possible, banks avoid implementing new and complicated authentication schemes that would be inconvenient for their customers. When it comes to stronger online authentication, most financial institutions have been waiting either for other institutions act first or for another more palpable authentication option to emerge. Fortunately, a new option just did. Risk-Based Authentication TowerGroup defines "risk-based authentication" as an authentication approach that utilizes both requested and observed customer information, along with data supplied during Internet communications, to assess the probability that each customer interaction is authentic. Requested customer data includes the traditional username and password but may also include other attributes that are gleaned from the Internet communications established between the user and the institution. Observed customer data includes a handful of specific attributes provided from the Internet communications between the user and the institution as well as customer behavior and transaction patterns. This information represents an additional authentication factor that augments

2002 - 2005 The Tower Group, Inc. May not be reproduced by any means without express permission. All rights reserved.

the username and password, making this an enticing multifactor authentication technique. Risk-based authentication assessments occur at initial login and may also be performed at each interaction during a secure session as well as during transactions specified as high-risk. The key advantage of risk-based authentication is that no additional hardware or software is required, making this approach seamless to the end user (other than the potential use of challenge questions if the authentication is in question). The effectiveness of risk-based authentication is comparable to that of hardware- or software-based authentication approaches, but they are far less expensive to implement and manage. The adage that the Internet is anonymous is not completely true. Quite a bit of information exchanged during any Internet session can be used for authentication purposes. In order for Internet communications to take place, some basic information must be shared between the sender and receiver. The communications protocol for the Web is Hypertext Transfer Protocol (HTTP), which is based on a simple request-response model. The HTTP request defines exactly what is being requested from a Web server, along with additional information needed for the Web server to properly process the request. This information, provided in the HTTP header, includes such data as the requesting URL, the type and version of browser being used, and the language and file types the requestor can accept. Other information may or may not be provided in the HTTP header, but it can be used for identification purposes if present. Besides the information it obtains from the HTTP header, a Web server can return computer code to the requestor's machine to gather information with the intent of profiling the PC. For example, the Web server may ask for the PC's time, time zone, or software versions. This data can be used to create a device fingerprint, which is a detailed profile of the PC's characteristics to compare with those in future authorization attempts. Given that users can change access devices, this is but one source of data used in risk-based authentication approaches. Another, and perhaps more intrusive, approach is to download a cookie onto the user's PC to use as one of the authorization attributes. Aside from some of the information contained in the HTTP header, much of the directly requested data described above is vulnerable to fraud. Although it is difficult to do, a criminal could poll a user's PC and then replicate the settings on a different PC with the intention of fooling the authentication system. The hacker would have to know all the specific attributes that the authentication algorithms are looking at and then painstakingly replicate the attributes. Fortunately, the difficulties in performing this feat, along with the availability of indirectly observed data that cannot be spoofed, make risk-based authentication more effective. Indirectly observed data, which is that not provided by the user (i.e., username and password) or the user's PC (e.g., time and time zone), can also be used for authentication purposes. Some of the data included on the HTTP header could be considered indirect information, such as the IP address and type of connection, because it cannot be effectively spoofed in a manner that would enable the perpetrator to commit fraud. Information about a user's behavior, like time and frequency of access, common transactions performed, and site navigation characteristics, can also be observed for use in risk-based authentication. For example, some individuals travel extensively while others access the bank only from home. Users also have varying login frequencies and access times. The profile created for each user indicates expected behavior patterns whose violation may not, by themselves, be indicative of fraud but can be used in conjunction with other indicators in risk-based authentication decision making. For example, a login request originating from a foreign country may be assessed and treated differently for a user who travels frequently than for a user who always logs in from home. Exhibit 2 provides several examples of directly and indirectly observed data used in risk-based authentication.

2002 - 2005 The Tower Group, Inc. May not be reproduced by any means without express permission. All rights reserved.

Exhibit 2 Examples of Data Directly and Indirectly Collected for Risk-Based Authentication Source: TowerGroup

Internet User Identifiers The request-response paradigm of Internet communication most often uses HTTP to define what and how each party should communicate with others. To initiate a request for information, the requestor must provide some basic information that explains what is being asked for, who is asking for it, and in what formats the information can be delivered. Other information is often required as well, such as the requestor's preferred language or e-mail address, but it is not always necessary for communications to take place. From the basic set of HTTP information, we can determine the requestor's host site and IP address, a description of the browser and usually the operating system, and if used, the referring site from which the end user came. Risk-based authentication systems use the data supplied during Internet communications as additional factors for analyzing a user's authenticity. Some risk-based authentication systems have methods for obtaining and utilizing information to supplement the basic information supplied during typical Internet communications. The systems commonly use any combination of the following Internet user identifiers: IP address, customer behavior profile, device profile, and device identifier. IP Address The IP address forms the foundation of risk-based authentication. From this one data point, a variety of data can be gleaned and used to assess the risk of each interaction. Because of the dynamic nature of IP addresses, simply maintaining an IP address on file for comparative purposes is useful but not entirely sufficient. Several vendors (most notably Digital Envoy and Quova) provide IP geolocation technology to match a variety of information about physical and cyber location to an

2002 - 2005 The Tower Group, Inc. May not be reproduced by any means without express permission. All rights reserved.

IP address. These companies continually monitor the universe of IP addresses to ensure that their information is current and accurate. Exhibit 3 lists some of the information that Quova determines for any given IP address in the world. Similar IP geolocation information is provided by Digital Envoy.

Exhibit 3 Example of Data Provided by Quovas GeoPoint Application Source: Quova

One of the interesting capabilities that IP geolocation provides is calculating travel times to determine if a user could have had time to travel to the location of the most recent login. That is, if a user accesses the institution from Chicago and then three hours later attempts to log in from Beijing, unless the individual somehow acquired a Star Trek teleporter, the likelihood that the login is fraudulent is fairly high. Other IP geolocation capabilities include the identification of:
Mismatches between the IP server's physical location and the user's historical access locations (which may prompt the user to answer a challenge question, as discussed below) Access attempts from countries or cities deemed high risk because of extensive known fraudulent activity and from countries sanctioned by the US Office of Assets Control (OFAC) Anonymous proxy servers, indicating that the individual may be attempting to hide his or her identity (discussed further below)

2002 - 2005 The Tower Group, Inc. May not be reproduced by any means without express permission. All rights reserved.

Customer Behavior Profile Monitoring the way customers interact with the institution also provides valuable information to use in risk-based authorization decisions. Because a customer's behavior cannot be easily spoofed, it serves as useful information about the customer interaction for use in risk assessment. Customer behavior information can be linked with IP geolocation data to enrich the profile of each customer. For example, some customers log in primarily from their homes or offices, whereas others who travel extensively log in remotely. Some customers perform all their online bill payment transactions at the end of the month, and others pay throughout the month. Knowing the standard behavior patterns for each customer allows the institution to identify out-of-pattern activities that could indicate fraudulent activity. Behavior profiles can be, and should be, extended to include transaction profiles for each customer. It cannot be stated enough that the more information available to assess each customer interaction, the more accurate that assessment. Device Profile Some risk-based authentication approaches include the use of dynamic HTML with Java or JavaScript to profile various elements of the user's PC. Through this approach, several other factors can be accumulated for use in authentication, such as the PC's time, time zone, or plug-ins as well as many other system attributes. The more parameters that are collected, the more accurate the risk model will be. Users must be told that the institution, as part of its authentication process, will poll their PCs for access purposes but will not use or share the data collected for any other reason. As important, this data, and all data collected and stored as part of risk-based authentication, must be securely maintained within the institution. While it is possible for a user to block the use of JavaScript, this action in and of itself can be used as an indicator of the user's intentions. As a matter of course, the institution may decide to disallow access to any user who has blocked the use of JavaScript, deeming this suspicious activity. Device Identifier Another method for confirming the authenticity of a user login is using secure cookies or Flash shared objects. These files are placed onto the user's PC during a secure session and are used to assure the access device's authenticity at subsequent logins. While this approach may seem intrusive, the end user should be asked to authorize the use of these files after learning how the files are intended to be used for authentication purposes. Although the device identifiers could presumably be stolen by a hacker attempting to spoof the user's PC, the use of other factors during risk-based authentication should negate the impact of this type of highly targeted event. How Risk-Based Authentication Works A risk-based authentication system consists of several components and should ideally be linked to the institution's customer information file (CIF) to better enable the system to assess each interaction in relation to past interactions. Typically, the initial login is analyzed and assigned a risk score when the data collected during the login is compared with data residing in the customer's credentials database (username and password), the IP geolocation database, and the customer profile database. The authentication engine is guided by the rules defined in the authentication rules database, which is typically configurable by the institution and extensible to allow new rules. See Exhibit 4 for an overview of the risk-based authentication process and components.

2002 - 2005 The Tower Group, Inc. May not be reproduced by any means without express permission. All rights reserved.

Exhibit 4 Risk-Based Authentication Process and Components Source: TowerGroup

The user can be approved or denied access based on the assigned score and the institution's tolerance limits. Users who do not score adequately to warrant full access can be allowed limited access or be required to provide more authentication to gain full access or be permitted to perform certain high-risk transactions. Several approaches are available when more authentication is needed, including:
Require the user to respond to one or more challenge questions that either have been pre-answered and stored in the customer profile or are based on information that the genuine account holder should know Use alternative channel authentication methods, such as cellular phone or e-mail, to contact the account holder, have the account holder contact the institution, or alert the user to questionable transactions Provide the customer with account access, but place all transactions on hold until the customer can be contacted for validation; however, because many transactions are executed in batch mode (rather than real time), this approach may not alter the timing of the transaction execution

Ideally, the risk-based authentication system continues to monitor the entire session after the initial login. The more information that is collected during a session, the more accurate the system. For example, if a user who was allowed access with a borderline score proceeds to create a new bill payee and then send half of the account's value to that new payee, the system would flag this

2002 - 2005 The Tower Group, Inc. May not be reproduced by any means without express permission. All rights reserved.

action as being high risk and at minimum flag the session as potentially fraudulent. Any questionable activity identified by the authentication engine is sent to a case management tool for human intervention. Cases are prioritized based on risk level and provide a complete picture of risk associated with those interactions with high risk scores. The resolution of cases can and should be fed back into the authentication risk engine to create a self-learning loop to improve future performance. Administration and reporting tools should also be available for the institution to better understand and control the risk-based authentication system. These tools allow the system users to easily analyze and report on system performance, identify scoring or access inconsistencies and areas for improvement, and track system users' actions and performance. Further, reporting tools provide an easy way to present detailed performance information to senior management and fraud analysts. The Risk in Risk-Based Authentication No authentication approach is 100% foolproof, at least without being prohibitively complicated or expensive. The typical username and password combination, along with the stronger hardware authentication device approaches, uses a simple binary decision-making process. The authentication is either right or wrong; the user is either allowed or denied access. Although riskbased authentication decisions are not as straightforward, they can be as effective as or more effective than the hardware-based solutions. The key is to collect and evaluate the right parameters according to the right rules and then execute the right response. The two types of errors that can occur in a risk-based decision algorithm are false positives and false negatives. False positives, or false alarms, occur when an access request is deemed to be fraudulent although it actually is legitimate. The harm with false positives is in blocking out a legitimate user or asking the legitimate user for additional authentication information. Most riskbased authentication vendors recommend the use of more authentication factors to reduce the likelihood that legitimate users are denied access. A high incidence of false positives would ultimately annoy customers who are continually asked for such information or denied access. False negatives occur when the system incorrectly authenticates and allows access to a fraudulent user. Of course, the primary goal of an authentication system is to ensure that very few illegitimate users ultimately access the system. Risk-based authentication systems are driven by rules generated by the institution. The tighter the rules for preventing fraud, the higher the likelihood of false positives and vice versa. Generally, these systems can be tuned to provide a reasonable balance between false positives and false negatives, with system performance continually improving as more data is collected and analyzed and the systems continue to self-tune. Aren't There Ways to Fool Risk-Based Authentication? As previously stated, no authentication solution can be 100% foolproof. Every solution has vulnerabilities that are typically known and managed by the institution. For example, we now know that usernames and passwords are vulnerable to phishing scams and that key loggers and hardware tokens are vulnerable to man-in-the-middle attacks. Understandably, several questions have been raised about some of the obvious, potential vulnerabilities related to risk-based authentication. Proxy Servers Proxy servers sit between the client and the Internet and are generally used to improve system performance and filter requests. While most proxy servers (like those from AOL, Compuserve, and some large corporations) are put in place for legitimate business purposes, some exist solely to mask the identity of the end user. A good example is a server from Anonymizer, Inc., which is in business to provide a legitimate and useful service: Web privacy. Although the service exists to "defend users from the most prevalent Internet privacy and security threats, from online tracking using cookies to malicious code, identity theft and email spammers," the service, and many like it,

2002 - 2005 The Tower Group, Inc. May not be reproduced by any means without express permission. All rights reserved.

can also be used to hide a fraudster's identity and IP address. Fortunately, the IP geolocation services can readily identify a proxy server as the source of a Web request and even go so far as to distinguish between legitimate private proxy servers and anonymous proxy servers (those that are put in place to hide a user's IP address). A user who typically visits the bank from the AOL private network will be identified as such and expected to connect in this manner. A user who attempts to access the bank from an anonymous proxy server will raise a red flag because these sites are closely associated with a high likelihood of fraud. Although a risk-based authentication system using IP geolocation cannot "see through the proxy," it can assess the risk associated with the proxy server's being used for each login attempt. IP Spoofing The IP address included in the HTTP header can be altered so that the message seems to be coming from an IP address other than the fraudster's actual IP address. Although this approach has been used for denial of service (DoS) attacks, it is ineffective for fraudulently accessing an online bank account because the institution will think that the request came from the spoofed IP address and will subsequently send replies to that spoofed IP address (not the fraudster's actual IP address). A fraudster cannot create a normal network connection by spoofing the source IP address because the response will be misdirected, and no meaningful communication can take place. That is, the server will reply to the spoofed IP address, so the fraudster will not receive the response. Man-in-the-Middle Attack or Session Hijacking Because the IP location forms the basis for risk-based authentication, it is one of the few approaches that defend effectively against the man-in-the-middle attack wherein a fraudster acts as a conduit between the user and online banking site, intercepting all correspondence between the client and host and potentially taking over the session to commit fraud. The institution will see the IP address and associated data from the man-in-the-middle and recognize that it is not the end user. Moreover, session hijacking can be identified only if the institution continues to monitor the IP address of packets sent after the initial authentication. This sudden change in IP address will immediately alert the risk-based authentication system that the account has been hijacked. Risk-Based Authentication Vendors The market for risk-based authentication solutions is young. To date, only a few installations have been publicly disclosed, none of which incorporates the full suite of tools that are available in a riskbased authentication system (as previously defined). Several institutions are conducting risk-based authentication system pilots, and others have implemented versions under strict nondisclosure agreements. Vendors highlighted in the following sections provide IP geolocation and risk-based authentication solutions. TowerGroup will review these vendors and their products in more detail in a forthcoming research note. IP Geolocation Vendors Some of the larger financial institutions have been using IP geolocation technology as part of their online authentication process to identify access requests from locations known for fraud, including specific Web servers and foreign countries. Some of these institutions use IP geolocation technology for marketing purposes as well. The two leading providers of IP geolocation technology in financial services are Digital Envoy and Quova. Both vendors are known to provide highly accurate and timely IP geolocation data that is continually monitored and updated for the more than 4 billion IP addresses worldwide. Risk-Based Authentication Vendors Most of the risk-based authentication system vendors incorporate IP geolocation data as part of their solution approach. In fact, Digital Envoy is one of the vendors that have expanded their solution sets to include risk-based authentication. One of the largest and best-known online banking application providers, Corillian, is now providing a risk-based authentication solution. Other risk-based authentication providers include the 41st Parameter, Cyota, and PassMark, all of which
2002 - 2005 The Tower Group, Inc. May not be reproduced by any means without express permission. All rights reserved.

10

focus exclusively on antifraud and risk-based authentication solutions for the Internet. In a watershed for the risk-based authentication approach, Bank of America recently announced the adoption of PassMark's authentication system for online banking fraud protection. TowerGroup expects other banks to follow suit, partnering with the vendors listed above to provide similar protection for their online consumer base. Summary With any luck, the financial services industry will quickly realize the devastating effect that a spike in online fraud would create for online banking and e-commerce in general. TowerGroup continues to promote the use of stronger authentication technology as an effective weapon to combat consumer data theft. Fortunately for the industry, the emergence of risk-based authentication technology provides a cost-effective, low-impact approach to strengthen online authentication without hardware-based authentication devices. Today, risk-based authentication systems are just developing, but they are continuing to improve as implementations are stressed in live production environments. Any financial institution with an online presence should earnestly investigate riskbased authentication as an alternative to other multifactor authentication approaches.

2002 - 2005 The Tower Group, Inc. May not be reproduced by any means without express permission. All rights reserved.

11