Fighting the last war

Most banks and e-commerce sites fall one step behind, responding to Trojans that steal log-on credentials by creating more complex authentication schemes and implementing two-factor authentication solutions. Today, banks frequently require that users click on-screen, randomized keyboards; type in the random letters of a "magic word"; or enter information from a hardware-based cryptographic key fob. None of these solutions works against the new breed of SSL-evading Trojans.

"It's not a problem of authentication but one of transactional authorization," says Bruce Schneier, leading security expert and CTO of Counterpane Internet Security. "No matter how hard you make the initial authentication for the end user or hacker, the malware can just wait until the authentication is done and then manipulate the transaction."

For example, you think you're checking your bank balance or writing an online cheque to pay a bill, but the Trojan is transferring your bank balance to a bank account in the Cayman Islands.

"The real problem is that we are allowing computers to make transactional decisions for us on our behalf, and the computer really doesn't know what is right or wrong," Schneier explains. "The consumer may not be able to see the real transaction to put a stop to the automated authorization approval, and the bank really has no way of knowing that a Trojan is making the decision, and not the customer."

Even more disturbing is that most banks and regulatory officials don't understand the new threat, and when presented with it, hesitate to offer anything but the same old advice.

Every bank and regulatory official contacted for this article said they have already recommended banks implement a two-factor or multifactor log-on authentication screen. In general, they expressed frustration at the amount of effort it has taken to get banks to follow that advice. And all complained about the trouble these schemes are causing legitimate customers.

When told how SSL-evading Trojans can bypass any authentication mechanism, most offered up additional ineffective authentication as a solution. When convinced by additional discussion that the problem could be solved only by fixing transactional authorization, most shrugged their shoulders and said they would remain under pressure to continue implementing authentication-only solutions.

They were also hesitant to broach the subject with senior management. It had taken so long to get banks to agree to two-factor authentication, they said, it would be almost impossible to change recommendations midstream. That puts the banking industry on a collision course with escalating attacks.

Verifying real transactions

Workable answers to the SSL-evading Trojan problem aren't necessarily more inconvenient than two-factor authentication solutions. They just have a different focus: transactional authorization. Solution providers need to realize that any authentication mechanism can be bypassed, and instead focus more on the right long-term answer.

Some banks now send consumers an "out-of-band" authorization code -- that is, not through the PC, but via voice message or text message through another device -- to type in and confirm a particular transaction. Unfortunately, the bank is confirming the transaction as the bank sees it, whereas an SSL-evading Trojan could be manipulating what the customer thinks the bank is getting ready to do. The customer may think he or she is making a small transaction, whereas the bank, because of the Trojan, is closing an account and making a transfer of funds to another bank.

In this case, sending an authorization code to the customer by itself doesn't work because the consumer is confirming a transaction he or she can't really see.