Like a lot of people, Washington Mutual's Dave Cullinane thought the time finally might be ripe for retail banking customers to start logging on by using tokens or other hardware-based authentication.
Regulators have given banks until the year's end to strengthen sign-on beyond user name and password—that woefully inadequate control that phishers have been bilking for years. If fraud losses weren't enough of a business driver, maybe the U.S. Federal Financial Institutions Examination Council (FFIEC) regs would be. And surely at least Washington Mutual's technically sophisticated home crowd in Seattle would be happy to dangle a dongle from their key chains.
But the idea went over about as well as decaf in the cockpit of a 6 a.m. flight to San Jose. More than 90 percent of the participants in several focus groups said they didn't want to use a token to access accounts online or by phone.
"The response we got was, 'Don't tell me I have to carry something to get access to my money. It's your job to protect my money, and if you don't do your job I'll find someone who will,'" says Cullinane, who is CISO of Washington Mutual, the nation's largest savings bank. "It was rather startling to get that from them."
From coast to coast, focus groups conducted by U.S. banks large and small must have said the same
thing. While tokens have long been used by commercial banking customers, an anticipated roll-out of hardware-based authentication to consumers has largely failed to materialize. Why? Customers say they don't want to bother; and customers, as legend has it, are always right.
Instead, to comply with new banking regulations and stem phishing losses, banks and the vendors who serve them are hurriedly putting together multipronged strategies that they say amount to "strong" authentication. The emerging approach generally consists of somehow recognizing a customer's computer, asking additional challenge questions for risky behavior and putting in place back-end fraud detection. But whether these layers of security combine to create something better—or worse—than traditional two-factor authentication is still anyone's guess
"I wouldn't discount anything because we're in that evolutionary stage when it comes to two-factor authentication," says Howard Schmidt, former White House adviser on cybersecurity and a longtime
proponent of tokens. "All these [emerging authentication methods] have the potential of raising the fence to keep out fraudsters. The proof will be once these things are fully vetted. That's what will separate the novel solutions from those that do a lot to enhance long-term security."
In the meantime, what changes are online banking customers likely to see? Not a whole lot. And for the banks, that's precisely the point. If they don't make it easy for their customers to do online banking, their competitors surely will. Explains Jim Smith, executive vice president of Wells Fargo's Internet
Channel and Products: "What we're trying to do is not get in the way of the customer experience."
A Layered Approach
A year ago in October, the FFIEC released new guidelines requiring banks to enhance online and telephone authentication by the end of 2006. At first, the FFIEC guidance was widely expected to usher in a new era of two-factor authentication for online consumer banking. On closer inspection, though, observers noted that it actually prescribes "multifactor authentication, layered security or other controls reasonably calculated to mitigate those risks" in cases where single-factor authentication is not enough. Analyzing the specifics of the guidance in these pages, CSO Senior Editor Scott Berinato wrote, "That's enough wiggle room for a conga line." (For more on the FFIEC guidance, see Second Thoughts on Second Factors
The conga line is now in full swing, and to understand the direction it is headed, just take a glance onto the dance floor of Zions Bancorporation, a fast-growing regional bank based in Salt Lake City that had 2005 revenue of $2.35 billion. There, Senior VP and CISO Preston Wood is overseeing a technology deployment that a year ago would have been considered groundbreaking, but that now has become a typical approach for a Fortune 1000 bank.
Wood is rolling out several elements of an RSA suite called Adaptive Authentication—none of which is the vendor's signature SecurID token:
1) Device authentication. The first time a banking customer logs on, Zionsbank.com places a small cookie or Macromedia Flash object (similar to a cookie but stored in a different place on the hard drive) on his computing device. The site also records details of the computer, from its IP address to the type of browser used to the time-zone setting. Then, each subsequent time the customer logs on, the website matches these details against what it has on record.
2) Mutual authentication. The customer also picks an image that he will use to authenticate the site. When Zionsbank recognizes his computer, the image appears, giving the customer some measure of assurance that he is not at a spoof site. This method was pioneered last year by the Bank of America.
3) Challenge/response component. A first-time website visitor is also asked to answer several questions from a list of questions provided by RSA that, theoretically, should be easy for him to remember but hard for a phisher to learn—typically things like the high school he attended or the first street he lived on. If Zionsbank doesn't recognize his computer, it prompts him with one or more of these challenge questions and won't let him in until he answers correctly.
"We're trying to balance increasing security for customers on the site while maintaining usability and portability," says Wood, who hasn't entirely ruled out traditional two-factor authentication for the future. Rather, his goal was to put something in place that can grow. For instance, he could set up the RSA system to incorporate out-of-band communication for certain kinds of transactions—perhaps requiring, say, a customer doing a large funds transfer first receive a passcode at a predetermined phone number.
"This establishes the foundation," Wood says. "As we want to, or as the threat necessitates, we can turn on additional features."
Finding Problems
The big question on Wood's mind—and everyone else's—is how quickly the threat landscape will change. And that depends largely upon what happens once the phishing community really starts trying to cut in on the dance.
The effectiveness of device authentication, for instance, varies widely. Don Phan, a research analyst at Javelin Strategy & Research, puts cookies on the lower end of the sophistication scale, along with
solutions that look at a computer's browser, other installed software, basic settings or IP address. More sophisticated solutions can do a BIOS scan on the motherboard and gather serial numbers.
When coupled with something the user knows, like a password, any of these types of device authentication, technically, constitutes a second factor for authentication—something the user
has, namely, a computer. But there are two main problems with authentication based on a computing device.
First, portability: Banks have to decide whether they want to provide a back door for customers who are logging in from a different computer than usual. Do online strategists want to let someone log on from a work computer or his mother-in-law's house? If so, they'll have to fall back on the other security "layers," like the challenge questions.
The second problem is that, to varying degrees, any of the device authentication methods can be defeated, spoofed or stolen. Second-factor authentication based on a cookie in a Web browser is especially troubling to some—and not only because some users don't allow cookies to be saved.
"The whole cookie technology has come a long way," says Stephen Northcutt, director of training and certification at the SANS Institute, which is known for its security research and certification programs. "It's an electronic hash, a numerical value that's something about your bank account. If no one else has access to that, it's fine. But here's what we could do to attack it: If it's a cookie, it can't be very well protected. The next thing you know you'll have some worm that goes through and collects cookies and e-mails them to an account in China."
In addition, security experts are increasingly concerned that the fraud community will migrate from the use of covert keystroke-loggers to screen-capturing technology—also called "screen scraping." This would allow them to routinely collect, in addition to keystrokes, the pictures that supposedly allow a banking customer to confirm he is at the right website. Then they could use those pictures to create customized phishing websites that more online banking customers will fall for—thus nulling the mutual authentication aspect that the cookie provides.
Likewise, the effectiveness of challenge questions can vary. Ask too obscure a question, and customers are likely to forget the answer they provided; ask too common a question, and phishers will simply log it along with user names and passwords. "It's become the latest hacking game to see who can get those questions," says Avivah Litan, vice president and research director at research firm Gartner.
Cullinane says that Washington Mutual tapped into the expertise of one employee with a psychology degree to help determine a sizable set of effective questions that people were likely to remember. Other banks are taking another route entirely. Wells Fargo, for instance, asks challenge questions based on information from a person's credit report or credit history—whether she has a credit line with a certain company, say, or whether she lived at another address four years ago. Another approach: The identity verification vendor Verid creates a set of multiple-choice questions drawn from public records, assigning a risk score based on how many answers the customer gets right.
If any of this isn't done carefully, of course, the system pushes out a lot more personal details than customers may feel comfortable with. Furthermore, the problem with any type of challenge question is that the answer is still something the user knows, which means the authentication is still single-factor.
Proponents of these layered solutions, however, are quick to point out that two-factor authentication isn't a perfect solution either. In the months since the FFIEC guidance was issued, tokens have lost some of their swagger. Even RSA offers examples of how tokens can be exploited.
Amir Orad, VP of marketing for RSA's consumer solutions business unit, says one new attack RSA has seen—although not yet in consumer banking—is best described as a transaction trojan. This piece of software waits on a computer until the user logs on to a certain website, and then runs a script in the background transferring funds. There's also growing concern over "man in the middle" attacks. In this type of ploy, the fraudster sits between the customer and the banking website. In one small but oft-discussed attack spotted last summer, for instance, phishers created a spoof of the log-on page for CitiBusiness clients, who use tokens to log on to the site. According to researchers at Secure Science Corp., when users entered the onetime password generated by the device, the phishing website relayed that information to the real CitiBusiness site, thus gaining account access.
Still, all these vulnerabilities are no reason to throw your hands up and cry "uncle." Giving up, says Schmidt, a former police officer, would be akin to "someone in the neighborhood watch saying, 'I never lock my doors because then someone would just kick the door in.' Everything we do to move away from user ID and password, every time we do that, we move further up the chain [toward preventing] something bad happening."
Beyond Authentication
Despite the FFIEC guidance about authentication, the emerging technologies that actually seem to hold the most promise for protecting the funds in consumer banking accounts aren't authentication systems at all. They're back-end systems that monitor for suspicious behavior.
Some of these tools are rule-based: If a customer from Nebraska signs on from, say, Romania, the bank can determine that the log-on always be considered suspect. Others are based on a risk score: That log-on from Romania would add points to a risk score, and when the score reaches a certain threshold, the bank takes action.
Flagged transactions can get bumped to second-factor authentication—usually, a call on the telephone, something the user has. This has long been done manually in the credit card world. Just think about the last phone call you got from your credit card company's fraud department when you (or someone else) tried to make a large purchase with your credit card in Europe. Some banks, including Washington Mutual, are in the process of automating out-of-band phone calls for risky online transactions.