Multifactor and Multichannel
powers-old-account 270000NC1K Comments (2) Visits (2003)
Many IT security folks have been following the case of Patco Construction Company, Inc. vs. People's United Bank in the United States District Court of Maine. As I understand the current state of the case, a magistrate judge has issued a recommended ruling in the case, favoring the bank. But the judge has not yet issued a final ruling.
The heart of the case centers around the authentication methods used to process online transactions from the customers. Many news outlets have over-simplified the ruling saying that the magistrate has recommended that "passwords + secret question" is sufficient for authentication. But whne you dig into the case, it's actually a lot more complicated than that. My favorite deep dive into the particulars of the case comes from the Krebs on Security blog. While the blog also makes the mistake of oversimplifing the case in the headline, it does a great job of concisely describing the arguments on both sides and the position that the magistrate took in his ruling.
I think a better headline would be "Bank sufficiently followed FFIEC Guidance" because the case centers around whether the bank had a reasonable implementation of multifactor authentication relative to the transaction risks being performed through the online interface per the FFIEC's Guidance. The FFIEC Guidance states:
The FFIEC Guidance defines three types of "factors" for multifactor
The bank used a device fingerprint scheme that combined characterisitcs of the sending machine/browser, combined with IP address location and time of day as a "something the user is" factor and the account password as the "something the user knows" factor.
In addition, the Bank had scoring scheme in place that assigned a risk score to a transaction partly based on the amount of the transaction and the factor information. If a transaction had a sufficiently high risk, the end user was also asked one of several challenge questions associated with the end user's account.
I can't find any more details on what the challenge questions actually were. But I suspect that they were the typical "obscure" personal information type questions such as "What is your Father's middle name?" What's interesting to me about the challenge questions with regard to this case, is that they are mentioned in the court documents but aren't central to any of the arguments. And in particular, the challenge questions aren't claimed to be one of the factors. At best they are surrogates for the password, "something you know" challenge. This is a long standing pet peeve of mine. Personal information, no matter how "obscure" should never be used as a surrogate for knowing a password.
The magistrate in the case explicitly recognizes the concept that a bank does not have to have "the best" / "leading edge" technology in place to have acceptable security. Furtthermore, the magistrate seems to have accepted that the banks claims on the password + device identity profile as counting toward having two of the three factors the FFIEC's guidance.
But the magistrate did lend, indirectly, some credence to one of Patco's claims. In their filing, Patco noted that the bank had made the challenge question routine for all transactions. They claimed that this greatly increased the risk of a Trojan on the Patco computer from getting access to the security question answer. While the magistrate didn't accept this argument as sufficient to prove the bank had inadequate security (especially in light that Patco had no forensic evidence to show that a trojanb had in fact stolen the secret question), the magistrate did give what seems to me a head nod to the idea that the current "two out of three" approach to multifactor authentication may be inadequate guidance from the FFIEC.
The magistrate included in one of his footnotes additional text from the FFIEC guidance, which neither party included in their court documents:
Let's grant for the sake of argument
that Patco is right. There was malware on the end user's machine that
managed to hijack both the password and challenge questions. Because
the malware was also installed on the local machine, the malware,
could in theory at least, hijack the device ID profile by simulating
the same channel that the end user typically used. This is not an
easy taks becuas the profile, as I understand it, includes even
things like the typical site navigation path the user
So an "out-of-band" factor becomes a very important aspect of multifactor authentication. Requiring that an attacker have command of two separate communication channels raises the bar very high for the attacker. Even simple out-of-band controls like sending a security code to a cell phone registered to the account is a big advantage over using additional factors going through one internet connection.
In fact, I'm in the camp of security folks that says this is such an important consideration that it is its own class of consideration when looking at authentication schemes. In other words, the communication channel used in an authentication scheme is not just another "factor" in multifactor authentication. Strong authentication schemes should be both multi-factor and multichannel.