|
||
|
||
Banks love it when their customers do their transactions on line, since it is so much cheaper than when they use a bank-provided ATM, a phone call center, or, perish forbid, a live human teller. Customers like it too, since bank web sites are usually open 24/7, there’s no line and no need to find a parking place. Unfortunately, crooks like on line banking too, since it offers the possibility of stealing lots of money. How can banks make their on line transactions more secure?
Bank web sites generally have enhanced “green bar” SSL certificates which makes them reasonably easy to recognize (at least for people who understand what to look for), but there are still lots of other security threats. On the web sites of my (too many) bank accounts, some have a two-page login in which the second page shows a picture and phrase selected by the user, which a fake site wouldn’t have. Some show a picture of a keyboard, on which I “type” a second password with a mouse to defeat intrusions that record the stream of keystrokes. Some show the keyboard, but just ask for three randomly chosen characters, to defeat attacks that steal credentials and reuse it to set up another session later. (There are 56 ways to pick three from an eight character password, making it unlikely that a later session would ask for the same ones.) One sent me a card with 50 random letters and digits, from which it again asks me to choose three. (That increases the odds to 1 in 19,600.) One bank in another country sent me a little keyfob with a pushbutton and display that shows a random six-digit number that changes every minute, so I can only log in if I have the keyfob. One sends an SMS to my mobile phone with a code that I have to enter, so only someone who has my phone can log in.
These all help somewhat, but given the ease with which most PCs can be controlled by hostile software, they all can be and are defeated by malware that takes over the user’s web browser, so the user does whatever the process is to log in, and then the malware can do fake transactions. That is, it’s a man-in-the-middle (MITM) attack, but with the middle being the browser, within what used to be considered a security perimeter. This is sometimes called man-in-the-browser (MITB).
At a meeting a few months ago, I heard about malware found in Europe that would replace a legitimate transaction with one sending money to the bad guy, and was sophisticated enough that when the bank sent a confirmation image file with a description of the transaction sending money to the bad guy, it recognized and rewrote the image to display the transaction the user wanted. With enemies that sophisticated, and compromises that complete, how can you hope for any kind of security?
The answer has to be to use a channel independent of the PC, that the bad guys can’t compromise. One approach would be to use a mobile phone as an independent channel: the user sets up the transaction on his PC and sends it to the bank, then the bank sends a description of the transaction including the payee, the amount, and a code to the phone by SMS. If the user agrees with the transaction, he sends back the code, either by SMS or on the PC. This would work fine on my phone, which is pretty dumb, but as phones get smarter and more computer-like, the chances of them catching their own viruses increases, and I’ve talked to at least one bank security guy who thinks he’s seen malware that runs on phones to do fake confirmations.
So what we need is something that has its own display to show a transaction, a secure way for the user to confirm the transaction, and a secure channel to send the confirmation to the bank, while being inflexible enough that malware can’t reprogram or otherwise compromise it. It seems to me that’s most easily implemented as a small device that plugs into the PC (often inelegantly known as a dongle), with a display big enough to describe a transaction, two lines of text perhaps, a pair of buttons for yes/no, an embedded serial number to uniquely identify it to the bank, and a communication interface, of which the cheapest these days is USB. One way to use it would be for the application on the PC to send the proposed transaction in the clear to the device, which would then display it. The user pushes the yes or no button, then the device adds its unique device ID and the yes/no flag from the button push to the transaction, signs the whole packet using a cryptographic key that the bank can confirm, and returns the signed package to the PC to be sent to the bank. Displaying the transaction on the device prevents MITM attacks in which the PC shows one transaction but submits another. Putting the yes/no button on the device prevents attacks in which the PC fakes a key press. And signing the transaction in the device keeps the PC or other MITM attacks from tampering with the transaction after the user confirms it. If the bank gets a transaction signed by the device they sent to that account holder, it can be confident that the customer did confirm the transaction since only the customer’s device could have done that.
The details could change slightly without affecting the security model. The “no” button isn’t really useful other than as a way to alert the bank that an attack may be in progress, so one button would be enough. If the transaction were more complex than a single yes or no, it might be easier to set up an encrypted SSL style channel between the device and the bank, using the PC just as a relay. A sufficiently paranoid bank might require a login into the device, so that the device can’t be misused if it’s lost or stolen. The essential bits are that the display to the user, and the subsequent yes/no confirmation happen directly in the device without a chance for the PC to interfere, and the message(s) sent back to the bank includes the details of the transaction, the device ID, and cryptographic protection of the confirmed message.
Would this be too expensive to deploy? I don’t think so. The keyfobs that some banks already give away have a one line display and a button, and memory sticks with USB connectors are cheap enough that I routinely get them as party favors at trade shows. This device has a bigger screen, perhaps three or four times as big, two buttons rather than one, and a USB adapter which some security keyfobs have already. I gather the basic keyfobs cost $5 in quantity, and USB security tokens that can do crypto are $50, so $50 seems like the right range if these were made in quantity.
While it might not make sense from the bank’s point of view to send every retail customer a $50 device, for businesses that routinely do on line transactions of tens or hundreds of thousands of dollars (including some widely reported fraudulent ones due to compromised PCs), I don’t understand why banks aren’t using this approach already.
Update: This level of security is well known in Europe, although not widely deployed due to a combination of the cost of the device and concerns about customer acceptance. IBM has an experimental device called a Zone Trusted Information Channel that isn’t exactly the same but accomplishes essentially the same result using a device with a USB plug, a small display, and a button.
Sponsored byWhoisXML API
Sponsored byCSC
Sponsored byVerisign
Sponsored byRadix
Sponsored byVerisign
Sponsored byDNIB.com
Sponsored byIPv4.Global
A World-Renowned Source for Internet Developments. Serving Since 2002.
John,
Not that I have anything against your idea - I like it - but there are other costs to consider. You began the article about how the banks love it when customers do online transaction because it is so cheap, even cheaper than an also-very-cheap ATM transaction, as there is no teller, ATM machine or brick-and-mortar facility. But like the extra costs of an ATM transaction that go beyond the cost of the few bytes transferred back and forth and the software interface, you have to consider other costs for the tactic you mention, namely bank help desk costs. In many enterprise environment, a 2-factor token-based approach like RSA SecurID is widely used. This is a token even simpler than you describe, one that is USB based and contains a simple 6-digit LCD that syncs with the central server and changes on the minute and when combined with your PIN authenticates you. But at an enterprise client site I am currently on, the number one help desk ticket among is lost or forgotten tokens or other token issues. There are more token-issue tickets than any other application. Yet, there is a help desk that understands you left it at home but still need to log on quickly in some temporary way without your token. Similar things would happen with banks, where someone would need to do their transaction (e.g., pay the mortgage or a bill or transfer funds before a check bounces) in a hurry somewhere and may be without their token. Suddenly you have a call center involved and the associated costs, and all the aspects of social engineering security threats to deal with to allow someone to do the critical transaction now but without their token. The same would apply if they lost their token and one was in transit to the their home. Not to mention the shipping costs, the person may still need to complete their transactions right away and will want the bank to facilitate. Either the bank has procedures for that (and the help desk staff to facilitate it while dealing with crooks faking the real user’s information), or you prohibit a customer from any transactions where they don’t have their token. To date, after more than a decade of performing online banking transactions I’m not sure I’ve ever needed to call the bank’s call center for help, but the probability might go up a little bit if another piece is added to the process. This level of security may be well worth the cost of the keyfob and support for it, but there will be that extra cost.
Even though I’d hate to have yet another bulky keychain item, I’d be all for what you suggest, I just don’t think it will be limited to the ($5 or $50) cost of the actual keyfob itself. And banks LOVE to nickel and dime you on fees.
A practical solution to the “insecure endpoint” problem, within everyone’s reach, is to boot the computer from a Live CD/DVD (like Ubuntu) when doing online banking. Such a system may contain security vulnerabilities, but the read-only nature of the system means that it can’t become “infected”—each reboot starts up the system in a known good state.
See also Brian Krebs’ article, “Avoid Windows Malware: Bank on a Live CD”.
That’s an interesting tactic and may be the way to go, but still, as the article suggests, the reasons many people use such services is convenience and speed as much as anything else. The more we do to compromise convenience, the less we like the service, and eventually we’ll just go back to the old method (and maybe go back to visiting the brick-and-mortar bank in this case). Having to reboot just to check a bank balance or do a quick transfer would be annoying to me, even if it was much safer. We usually are willing to compromise convenience to gain some level of security - getting through an airport to the plane comes to mind quickly - but at some point it’s too much. Of course, if security becomes an even bigger risk - and it seems almost like we are losing the battle - that may drive us back to the old methods even faster.
Example, one of my credit card companies is hyperactive about security. Maybe that’s a good thing but it has presented some major inconveniences to me that may be outweighing (at least as far as I can see) the security “benefits” that they claim they are rectifying with the added inconvenience to the end user. I haven’t canceled them yet and may not, but I’ve been tempted. But maybe they are doing the right - or only! - things that they can do.
Perhaps virtualization can help here, as it moves to end user PCs, can you set up a virtual machine that you can shell over to and use as your secure machine, just to avoid having to reboot?
John’s article seem to suggest that he was speaking not of businesses but of individuals like you or I who perform bank transactions online, and relatively few individuals have lost thousands much less hundreds of thousands of dollars performing such transactions. The day I lose what I deem to be a significant amount would be the end of such online transactions for me, and I’d go back to going to the physical bank, which would probably increase the cost of services for the bank and lower their opportunity costs. It’s up to the banks to solve all security issues, online or otherwise, while maintaining a reasonably convenient service offering. It is a customer’s expectation of the service. As John said, they love how much cheaper online services are for them, but they have to factor in the security costs. It’s no different than the expectation we have of traditional banking services being convenient – nearby branches, flexible night and weekend hours, enough tellers to reduce the wait, drive through lanes – as well as being secure – armed guards, surveillance cameras, alarms, tellers behind bullet proof glass, vaults, etc. We probably take all that for granted now even though banks still get robbed from time to time. But your average customer would not expect to personally pay for traditional old-fashioned security breaches that happen to the bank. The expectation is no different in the online world. The banks have to find a balance, providing a service that is secure enough to keep the customer’s confidence while also continuing to be convenient enough to be practical. Too much of one in spite of the other, and certainly too little of both, will drive customers away and back to the bank, resulting in more tellers, more branches, more hours, more drive through lanes, infrastructure, etc. Each of the financial institutions I deal with have stepped up their online security methods in increasingly more annoying ways, but what has been done so far is easily understandable and tolerable given the threat, even if it does present some compromise to convenience, which it has, albeit relatively small so far. It’s challenge for the banks for sure, but that’s the cost of doing business. In the end it is their service and it is our money.
As far as I know, the customers who have lost large amounts are all businesses at this point, but the transaction stealing trojans in Europe affect individuals. I agree, the trick is to find something that is adequately secure that users will be willing to use.