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.”
Bank officials concur. One regulator said, “Most banks, because of their customers, would probably not accept such an extreme form of authentication. How often would the out-of-band device fail or not be available? Requiring users to confirm every banking transaction out-of-band would not be accepted by today’s consumers.”
The regulator speculated that a better solution might be for the bank to offer out-of-band confirmations as an option and allow the consumer to pick the dollar amount at which the transaction would require additional confirmation measures.
Other bank security officers thought implementing added intelligence on the back end would provide more value. “How about not allowing online transfers to banks and countries with strong ties to crime?” offered one officer. “We could deny any transaction that the bank deemed highly suspicious, like your credit card company does now, and require a second confirmation.”
Close observation of consumer behavior can also help. In one case, nearly 100 customers of one large bank were infected with an SSL-evading Trojan. As usual, the phishing e-mail used mostly legitimate links to the real bank’s Web site. After noticing outside requests to links, most of which were normally referenced from other internal links, the bank’s IT staff realized a Trojan was to blame.
The solution was to rename one of the requested links. If any user went to the real bank’s Web site, the renamed link was now referenced by the legitimate Web site. Only the phishing customers would request the link’s old name, enabling the bank to tell how many of its customers were compromised.
Yunus Emre Alpözen, a consultant for one of the world’s largest banks, says, “Every customer requesting the old Web page link was redirected to a new page that notified them that they were the victims of a phish attack, and how to proceed. We used the phisher’s e-mail against them.”