Internet and e-mail policy and practice
including Notes on Internet E-mail


2009
Months
Nov

Click the comments link on any story to see comments or add your own.


Subscribe to this blog


RSS feed


Home :: Money

08 Nov 2009

How do you do secure bank transactions on the Internet? Money

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 devide with a USB plug, a small display, and a button.


  posted at: 22:34 :: permanent link to this entry :: 8 comments
Stable link is https://jl.ly/Money/securetrans.html

Topics


My other sites

Who is this guy?

Airline ticket info

Taughannock Networks

Other blogs

CAUCE
It turns out you don’t need a license to hunt for spam.
26 days ago

A keen grasp of the obvious
Italian Apple Cake
584 days ago

Related sites

Coalition Against Unsolicited Commercial E-mail

Network Abuse Clearinghouse

My Mastodon feed



© 2005-2020 John R. Levine.
CAN SPAM address harvesting notice: the operator of this website will not give, sell, or otherwise transfer addresses maintained by this website to any other party for the purposes of initiating, or enabling others to initiate, electronic mail messages.