Multifactor authentication and Patco Construction v. People’s United Bank
There was an interesting ruling by the United States District Court District of Maine in Patco Construction v. People’s United Banka few days ago. It seems that back in 2009, someone at Patco Construction managed to install Zeus malware on the computer that Patco used to initiate electronic funds transfers. This let hackers capture the answers to the challenge/response questions that Patco used to authenticate to their on-line banking system. The hackers then used this information to complete about $345,000 in fraudulent transactions. Patco sued to recover the lost money, claiming that the bank’s security measures were not "commercially reasonable." The court disagreed, and Patco’s suit to recover the money lost in the fraudulent transactions was dismissed.
What I find interesting about this particular ruling is part of why the bank’s security measures were found to be commercially reasonable. FFIEC’s guidance "Authentication in an Internet Banking Environment" (PDF) recommends multifactor authentication for financial transactions, but exactly what that means isn’t as clear as you might expect it to be. In this particular case, the bank claimed that in addition to a username and password plus the answers to challenge/response questions, that
its security procedures also employed "something the user has": device identification information specific to the client’s personal computer and its use of the Bank’s application, and "something the user is": taking into account user behavior.
But when the hackers compromised the username and password plus the challenge/response answers, they didn’t compromise these other factors. They didn’t get the ability to spoof device authentication information and they didn’t get the ability to spoof the behavior of the legitimate user. But that’s apparently OK. As the bank pointed out, in their legal arguments, Patco
attempt[ed] to manufacture an additional "requirement" for multifactor authentication, unsupported in the FFIEC guidance or in case law, by arguing that the system must respond in a certain way to each of the factors, for example, by blocking a transaction if one of the factors fails.
So it looks like the bank claimed, and that the court agreed, that it’s OK for some of the factors in a multifactor authentication to fail yet for the overall authentication to succeed. I haven’t carefully considered all of the implications of that, but my first reaction is that this is probably just an oversight on the part of the people who wrote the FFIEC’s guidance, and it’s something that the next version should probably address.
It also looks like people writing other standards should also think about this and consider explicitly requiring success from more than one of the factors in multifactor authentication for an authentication attempt to succeed. Maybe that’s something that the ASC X9F4 working group should consider, for example.