This summer, a Citizens Financial Bank customer from Indiana was granted permission to proceed with the first-ever court case alleging a lack of sufficient multifactor authentication for online banking protection. The judge in the case noted that only single-factor authentication
With the growth of online financial transactions -- and the rise in online banking fraud -- users will demand higher levels of protection, including multifactor authentication as required by the FFIEC. Putting these controls in place now is a critical step toward reducing financial data theft and fraudulent account activity, as well as avoiding potential liability for online fraud.
Multifactor authentication requires two of the following to be simultaneously presented for user authentication: something you know (such as a password); something you have (such as a dynamic PIN code or token code); or something you are (such as a fingerprint). Let's take a look at some of the more common multifactor authentication systems banks have implemented and some of the newer options to secure online banking and meet FFIEC compliance requirements.
One of the most common methods is the use of traditional hardware tokens with dynamic PIN generation. These tend to be very effective and scale well, but are difficult and expensive to deploy. For many larger organizations, this is simply not a feasible solution. In some cases, financial organizations are turning to "soft tokens," or software-based PIN generation tools that can be downloaded by users and installed on mobile phones. After a simple registration process, users can generate PIN codes on their mobile devices, essentially turning them into personal hardware tokens. This is more cost-effective and is rapidly gaining acceptance as a viable alternative to hardware-based tokens.
Another traditional method is the use of a one-time password (OTP), sometimes called a Transaction Authentication Number (TAN). With this system, each user is issued a unique card with a numbered list of single-use passwords or passphrases. Each time they authenticate, they use one of these (in sequential order), and then cross it off the list. The financial institution maintains a database of users and their respective lists, and tracks which OTP is currently slated for use. This system works fairly well, and is inexpensive to maintain since the technology involved uses software that keeps the server-side and client-side lists synchronized. The only drawback to OTP tools results from increased support costs when users misplace their lists or the list gets out of sync.
A similar type of system uses unique "bingo cards." These cards, offered by vendors such as Entrust Inc. (IdentityGuard) and TriCipher Inc. (Armored Credential System), contain a grid with numbers on one axis, letters on another (in most cases) and some values (usually numeric) on the grid itself. When a user signs into a banking application, she provides a username and password, and is then prompted to enter a series of values found at locations on the grid (for example, D2). Each card is unique (like OTP lists), and is easily and inexpensively replaced if lost. There are few drawbacks to the bingo card system aside from user support for lost cards. Other systems generate OTPs and send them via out-of-band (OOB) methods, such as SMS, email and phone calls.
Another twist on traditional multifactor authentication leverages the specific computer a user logs in from as one of the multiple authentication factors. By placing a cookie onto a system that has been used to successfully register, the user is then able to log in by entering a username and password, often accompanied by one or more answers to "personal" questions prearranged during registration. When users attempt to log in from systems other than these cookie-equipped machines, they are either denied access altogether or prompted to answer a more rigorous series of pre-established questions to authenticate.
The main issues with cookie-based authentication are corrupted or lost cookies, and a tendency to "fall back" to less secure authentication methods such as a series of personal questions if a cookie is unavailable or a system can't be identified. In most cases, these cookies are encrypted and not particularly useful if stolen via cross-site scripting and other attacks.
Some banks are turning to technologies that add a new element to the common multifactor authentication categories: something based on location. Although somewhat related to the "something you have" paradigm, this newer two-factor model, sometimes referred to as device fingerprinting, relies on geo-location from IP addresses, ISP connectivity, and other coordinates to correlate users with pre-existing profile information. Vendors offering this technology include 41st Parameter Inc., ThreatMetrix Inc., and Iovation Inc. Although this method is gaining in popularity, it is still not widely deployed due to a lack of confidence as a true multifactor authentication scheme. Many financial organizations and consumers feel that it's less mobile and flexible than other methods, and could be compromised if the endpoint is infected with malware.
Although rarely used, a final option that some organizations may employ is biometrics. However, given the cost and complexity of maintaining this type of solution, which involves sending users a fingerprint reader or something similar, is not practical for large-scale deployment.
To sum up, it's vital that banks and other financial organizations take the steps to implement secure multifactor authentication. Many different options are available, allowing even the largest organizations to add additional factors to identify legitimate users of Web-based banking and other applications. By not putting these solutions in place, banks risk penalties for non-compliance as well as possible liability claims and lack of consumer confidence in their online banking initiatives.
About the author:
Dave Shackleford is director of risk and compliance and acting director of security assessments at Sword and Shield Enterprise Security Inc., and a certified SANS instructor. He was formerly CSO at Configuresoft Inc. and CTO at the Center for Internet Security, and has worked as a security architect, analyst, and manager for several Fortune 500 companies. In addition to these roles, he has consulted with hundreds of organizations for regulatory compliance, as well as security and network architecture and engineering.
This was first published in November 2009