"What is the name of the city where you were born?" More and more frequently, users of banking websites are greeted with such questions when attempting to login. Why isn't the user able to view his account information after inputting his username and password? The customer was using a computer he hadn't used before, and the bank was verifying he was who he claimed to be by using a device identification (DI) application.
Recently there's been a boon in deploying device identification as a fraud-prevention strategy. With cybercriminals targeting online credit card transactions, new account registrations and account logins, financial institutions have begun to require more than just a user's IP address and login/password to verify that the person trying to access the account is in fact the user.
Device identification: How does it work?
Device identification reduces fraud risk by using a "device fingerprint:" a device identifier based on the user system's IP location and how it's configured . This fingerprint, over time, allows the institution to assign and track a "reputation:" a risk value assigned to the user system based on the digital fingerprint value and the institution's determination of the risk this device poses if it is not in the hands of the end user, a value derived from his or her transaction history.
Device identification creates this device fingerprint based upon, but not limited to, hashed values of the following information:
- Geo-location attributes -- a physical location value based on the incoming IP address (e.g. IP 192.xxx.xxx.xxx = Eastern Europe).
- Connection attributions -- a value based on whether the connection is through a dedicated network connection (e.g. a Citrix server) or the general Internet.
- Timing and time zone attributes -- how many connection attempts were made, and what was the time lapse between attempts? Also, when did the attempts take place (e.g. 2:00am in the end-user's time zone)?
- Network routing attributes -- how the system's traffic is routed (e.g. through untrusted networks such as Middle East -- Caribbean -- East Coast of the U.S.).
- Application attributes - how the application is accessing the website (e.g. using SSL or no security).
- Operating system attributes -- OS, browser, other system identifiers.
- Transaction behavior attributes -- what transactions are being made (i.e. transfer, purchases, etc.)?
- TCP Protocol attributes -- What TCP protocol is used to access the destination system (e.g. HTTP, FTP, etc.)?
- Reputation attributes -- previous values assigned to this system.
As the customer logs into the enterprise's client-side website or portal over a period of time, the device identification application begins to generate a reputation value for each user. The device identification application then compares the reputation value to a pre-assigned risk value. For example, if the device fingerprint values total to a weighted sum, let's say 70, this is compared to the minimum risk value, let's say 65. If the application recognizes the user's system based on its fingerprint value, the user is allowed to proceed. However, if the application does not recognize the system, it assumes the system is unauthorized, and the user must then provide a series of correct challenge responses to add the device to the list of the customer's known systems. If the user is unable to do so, access is rejected.
Benefits of device identification
Unlike multifactor authentication that requires the enterprise to assign expensive credentials to the user in order to authenticate against the company's Web-based applications, device identification is a deterministic, positive identification technology that relies on known attributes about the user's system, while allowing the user to continue to use relatively inexpensive username/password authentication. In addition, matching on a hash of collected device attributes rather than on individual attributes is more efficient, which suits high transaction environments.
Device identification applications are best suited for organizations that have large populations of users accessing sensitive information from the Internet. Banks, online retailers, credit card issuers and other such companies find great value in being able to recognize their users beyond a set of username/password credentials.
In cases of potentially fraudulent action, presenting the user with a set of easy-to-answer questions (assuming he or she is the legitimate user), rather than disabling his or her account, also improves the reputation of the organization and reduces the risk of alienating its customers. In addition, companies are beginning to use these applications at their Internet employee portals to control remote employee access in compliance with their corporate policies and procedures.
Potential drawbacks of device identification
Device identification can be rendered ineffective if it is configured incorrectly, or looks at values that don't conclusively identify the system. It can return false negatives -- not recognizing the examined device as a previously known device -- or false positives -- recognizing the examined device as a previously known device, when it has not been used to log on before.
Using an online investment firm as an example, a false negative can carry a high tangible cost of fraud. For example, not recognizing a returning cybercriminal who has stolen a customer's identity information could cause serious damage. With full access to the client's account, the cybercriminal could then purchase stocks and bonds or even close the account and cash out the customer's investments and send the funds to his or her own account. Similarly, the cost of a false positive, i.e. classifying a good customer as a cyber criminal, can have a direct effect on revenue due to potential order rejection, such as a client that wants to make a stock purchase before the market closes for the day, but cannot because the system doesn't recognize his device's fingerprint. These types of denials can also ruin the reputation of the organization, especially if a high-profile customer is accidentally rejected.
Things to consider before implementing device identification
A basic concern with all device identification applications is that the attributes of the devices being profiled will change over time (i.e., with the user changing Web browser applications, accessing the application through different IP routes while on the road or upgrading to a new operating system like Microsoft's new Windows System 7 all present instances where a legitimate user could be denied access based on incidentals).
Another concern is the inability to identify a user's system due to the lack of information available for collection. With more users concerned about applications collecting data on their Internet habits, many are installing software that allows them to browse anonymously. This keeps device identification applications from collecting system parameters they need to build device fingerprints. And customers aren't the only ones concerned with online privacy. Privacy laws in Europe -- and some being considered in the U.S. -- restrict the information that can be collected on users. Thus, companies are being required to allow their customers to opt out of device identification applications, forcing those companies to limit the actions the customer can perform. Further, as cybercriminals deliberately try to manipulate device settings on their systems in order to disguise or alter their device fingerprint, device identification 's ability to prevent fraud decreases.
In addition, device identification applications aren't free. Besides the cost of the software components -- device analyzer, reputation comparison, database for storing device fingerprints, configuration console, etc. -- companies must begin with an integration project to incorporate the device identification software into their current client-facing applications. This generally requires an architecture that is capable of allowing the components to interface with the company's authentication systems, their Internet-facing applications, their perimeter protection devices and their backend transaction systems.
Because of these considerations, companies should seriously weigh the value they will receive in implementing device identification applications against the chance that privacy laws and anonymizing software might invalidate this verification technique.
Is device identification right for your enterprise?
As the number of online transactions increases, cybercriminals will continue to attempt to access customer accounts for fraudulent activities, and the need for tools that enable accurate device identification will continue to grow.
But the devil is in the details. Companies shouldn't buy into business fears and rush to deploy a device identification application. A bad device identification deployment will lead to locking out customers, while allowing cyber criminals to gain access to valuable client information. (Also, it should be noted that there are other methods for securing these channels, such as creating dedicated network connections for customers or implementing strong authentication schemes, though these tend to be time- and money-intensive.) But for most large organizations that take their time, and that need to interact with a large number of customers over Internet connections, deploying device identification, with its reputation values and device fingerprint hashing, is the best option today for high-risk client-facing websites.
About the author:
Randall Gamby is an enterprise security architect for a Fortune 500 insurance and finance company who has worked in the security industry for more than 20 years. He specializes in security/identity management strategies, methodologies and architectures.
