Inconvenience of two-factor security pushes banks to "single factor plus" for online banking

For the nation's banking industry, the clock is ticking.  By Dec 31, banks and financial institutions had better move to something more than just user ID and password-level security (known as single-factor authentication) to grant customers online access to their bank accounts or else.
Written by David Berlind, Inactive

Play audio version

For the nation's banking industry, the clock is ticking.  By Dec 31, banks and financial institutions had better move to something more than just user ID and password-level security (known as single-factor authentication) to grant customers online access to their bank accounts or else. Or else what? Well, or else nothing. Last October, with the nation's online banking infrastructure under severe attack from phishers and other identity thieves, the Federal Financial Institutions Examination Council (the FFIEC) issued stern guidance to American banks to bring the security of their Web sites up to snuff by December 31st of this year.  The FFIEC's guidelines detail the benefits of moving from single-factor security (a form of security based only on "what you know") to multi-factor security (involves "what you have" such as an ATM card or "who you are" based on biometrics) but falls short of making multifactor security a requirement to satisfy by the end of 2006. Instead, the guideline concludes:

Financial institutions offering Internet-based products and services should have reliable and secure methods to authenticate their customers. The level of authentication used by the financial institution should be appropriate to the risks associated with those products and services. Financial institutions should conduct a risk assessment to identify the types and levels of risk associated with their Internet banking applications. Where risk assessments indicate that the use of single-factor authentication is inadequate, financial institutions should implement multifactor authentication, layered security, or other controls reasonably calculated to mitigate those risks. The agencies consider single-factor authentication, as the only control mechanism, to be inadequate in the case of high-risk transactions involving access to customer information or the movement of funds to other parties.

In other words, multifactor authentication is on the list of ways to address the problem, but it's not required. The implication is that, whereas authentication was previously carved up into just one,two, and three factors, now, there's someting like a 1b.  It's stronger than single-factor security, but not quite multi-factor security.

Why not move to multifactor security in earnest? It's too inconvenient. Not just for the customers of banks who would be forced to use a new security token or some biometric device with their computers, but also for the banks that would very likely end up in a customer support nightmare as a result of trying to roll out such solutions into environments that are far less predictable than the browser-based solutions in place today.  At least that was the conclusion of Stephanie Lewis (photo, left), an industry analyst with Jack Henry and Associates. During my recent visit to RSA Security's usability lab, Lewis was on-hand to talk about how Jack Henry views online banking security.  Jack Henry develops and hosts an online banking solution that's used by more than 1100 financial institutions, many of which are community banks and credit unions.

In many ways, the banking industry is a victim of its own success when it comes to the two-factor security that's a part of all ATM machines. The allure of being able to get cash out of our bank accounts at any time and at just about any place was and still is too strong for it not to be worth the inconvenience of carrying around what amounted to one more credit card (the ATM card) in our wallets. In fact, it was hardly inconvenient at all. So, whatever the banking industry comes up with in terms of equivalent security for online banking had better be no more inconvenient. Unfortuantely however, ATM cards don't work in our computers.  There isn't a place to insert them. We could add a device known as a card reader to our computers by way of our systems' USB ports, but, forgetting for a minute the support nightmare that could create, what must banks' customers do if they end up banking from friends' computers or kiosks at airport terminals? Bring the card readers with them everywhere they go? What if the system has no available USB ports?  What if it's a smartphone? You see? Already, the simplicity is spiraling into complexity.

Another approach might be to issue a different kind of security token for online banking. For example, RSA makes small SecurID tokens that you can hang on your keychain.  The tokens generate a new random number every sixty seconds, and, as long as you have it with you and you put that random number into your bank's login screen when attempting to engage in online banking, you're in (the bank has security solutions behind its firewall that generate matching strings of numbers on the same 60-second intervals, just for you). But there are a few problems with this approach too. Now, in addition to your ATM card, you have to carry yet another token around with you. For most people, that's asking a lot.  And, what if they get lost or you leave it behind when you go somewhere.  Then, you're stuck, locked out of your bank's Web site with no recourse except to find your token, or have it replaced (in quantity, RSA's SecurID tokens cost about $15 each).

So, for banks, and their solution providers like RSA, the trick has been to come up with "1b" or "single factor+" solutions: solutions that primarily rely on what you know, but that also emulate, to the extent that they can, what you have (the 2nd factor in true multifactor security). For example, in my podcast interview of RSA's senior vp of customer solutions Christopher Young, I heard about how RSA's solutions use certain techniques involving cookies and IP address that essentially turn your computer into a security token.  For example, one approach is to use cookies, IP addresses and other information (such as last login time) to establish a degree of confidence that a person attempting to access an account is who they say they are.  Young describes a usage case where, if you routinely use the same computer, RSA's solutions can detect that and, in the process, lower the barrier to entry.  But, if you log in from a new system, you may be challenged to enter more information that only you would know before being authenticated. 

The podcast interview, which is of both Young and Lewis is accessible via streaming or by download using the player at the top of this blog entry. Or if you're subscribed to ZDNet's IT Matters series of podcasts, it'll show up automatically in your media player and/or your portable MP3 player (if you have it configured that way).

Editorial standards