Patco vs. Ocean Bank

The closely watched case of Patco vs. Ocean Bank is working its way through the courts. The most recent public event in the case is the recommendation of a court-appointed magistrate. If, as seems most likely, the court adopts the recommendation, it will be very good news for the banks and bad news for small business.

Patco was the victim of a Trojan Horse attack using software called Zeus. The attack enabled the perpetrators to compromise the Patco's banking credentials and re-play them to transfer Patco's funds to themselves and even to draw funds against Patco's line of credit with Ocean Bank.

The fundamental common law principle is that banks are responsible for ensuring that transactions are properly authorized and that they must stand the cost of fraud. As individuals, we all rely upon this rule. So far, at least for consumer on-line banking, the banks have honored this obligation both for deposit and credit card transactions.

However, over time this principle has been eroded and limited by legislation, regulation, and contract, designed to encourage responsible behavior on the part of bank customers, particularly business customers.

Patco argues it did not authorize the transactions in question and that the bank should reimburse them for the losses. The bank argues that Patco's credentials were used for the transactions and that, therefore, under its agreement with the bank, Patco is liable.

Patco argues that the security mechanism offered to it by Ocean bank was inadequate for the application and environment. It seems clear, both technically and from the events in the case, that the mechanism failed. That is not in dispute. Patco argues that stronger, if more expensive, mechanisms are available, that they would have protected Patco, and that Ocean bank should have used them.

However, the magistrate finds that the mechanism chosen by the bank, i.e., UID and password with challenge-response based on three shared secrets, complies with regulation, is widely used and was agreed to by Patco. The magistrate finds that, as a matter of law, banks are not required to provide the best mechanism.

The regulation in question requires "two-factor" authentication. While this includes token-based or out-of-band authentication, which clearly resist the replay of the customer's credentials, it also includes weaker mechanisms such as challenge-response based on a set of shared secrets.

Note that challenge-response does provide some resistance to re-play, at least until all the shared secrets have been compromised. The findings suggest that the bank increased the likelihood that all three secrets would be compromised by lowering the threshold for invoking them to $1-.

Moreover, a decision that turns on Patco's agreement to the mechanism assumes that it, or any bank customer is in a position to judge whether or not the offering is secure for his purposes. I would assert that that is unlikely, that it is far more likely that the customer relied upon the bank.

There is nothing in the report to suggest whether or not, in choosing its method, the bank contemplated a key-logger attack as was used here. It is far more likely that, as Patco relied upon the bank, the bank relied upon its service provider.

As in most disputes, in this case there is plenty of blame to go around. The bank chose a weak security mechanism. Then, relying upon intuition, rather than knowledge, weakened it further by lowering the threshold. Patco did use a Zeus-contaminated machine. While the bank clearly wants its customers to resist contamination, it should have assumed that across all of its customers, at least some would be compromised.

Bad cases make bad law. I hope that this case will be settled, rather than appealed, so that it does not establish an anti-customer precedent. The common law principle is well-founded and we have an interest is preserving it.

An update to the Federal Financial Institutions Examination Council authentication guidance is expected shortly. Leaks suggest that, while the guidance will encourage improvements, banks will continue to enjoy wide latitude, including the continued use of challenge-response. Rather than looking to the FFIEC for guidance on how to improve their security, most banks seem to be hoping that whatever they are doing now will continue to be permitted.

We should not be surprised that banks want to transfer to the customer as much of the responsibility for secure on-line banking as possible. Neither should we be surprised that they prefer regulations and standards that reserve to them the greatest possible flexibility and choice. The banks should not be surprised that we will use them and their services only to the extent that we believe that we are safe when we do so.

As security professionals, we should be advising our small business clients to 1) resist Trojan Horse attacks by using a dedicated and locked-down machine for banking, 2) resist re-play attacks by preferring banks that offer either token-based or out-of-band authentication, and 3) use on-line banking to their advantage by reconciling their accounts and activity daily.

We should be advising our banking clients that they can improve both their competitive and security postures by employing token-based or out-of-band authentication. In a world in which all adults and many children carry mobile computing devices, the convenience of these mechanisms is improving and the cost is falling.

Neither Patco nor Ocean Bank were well served by the security profession. We must do much better if we want to be called security professionals and get paid the big bucks.