For example, you think you’re checking your bank balance or writing an online check 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 out and 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.

A better solution would be to send the consumer the relevant details -- such as the date, from, to, amount, and so on -- along with the authorization code, thus allowing the consumer to confirm the transaction. Some banks and e-commerce sites do this already using in-band e-mail confirmations.

Schneier has his doubts about the out-of-band approach. “These types of authorization schemes would work, but it sounds a little extreme as a solution. Unfortunately, we live in an economic reality where users will not accept extremes. They want convenience.”