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

←2009→ Months Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 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 posted at: 22:34 :: permanent link to this entry :: 8 comments comments...        (Jump to the end to add your own comment) Too expensive! It was seen in Germany a month back. http://www.wired.com/threatlevel/2009/09/rogue-bank-statements/ https://financialcryptography.com/mt/archives/001195.html The approach is called the Man-in-the-browser, and was originally written up here: http://www2.futureware.at/svn/sourcerer/CAcert/SecureClient.pdf https://financialcryptography.com/mt/archives/000758.html Since early 2006 when it was first spotted in European banks, it has faced a very slow take-up. I would speculate it is because there were easier pickings elsewhere. Using a separated device with a display+buttons is the standard full-secure model that was theoretically developed in the late 1990s by European banks getting into the web game. It was obvious then that the virally-promiscuous Windows OS would be the rot that undermined online banking. The model competed with others of course; in the end the American model of basic SSL+password won out. E.g., built the business, worry about the losses later. The problem with a separate dongle is it is too expensive. It isn't the unit cost that matters, ex-China, it is the deployment cost, which can be 10-20 times higher. So only $1 units count, and even then the deployment costs are high. This is why the Europeans have gone over to using phones to do the authentication. There, the deployment can come down into the sub $10 areas, which is worthwhile. In some places it is called Mobile-TANs. This system was rushed to completion in 2006 and phased in over the next few years. It isn't universal, but many banks have a proportion of their customers over on it, so they are in a good position. (by Iang 08 Nov 2009 14:59) Does the Mobile-TAN use SMS authorization via text reply or is this an automated or staffed voice system? Too bad black hats have shown their savvy with insecure banking pbx systems for lucrative phish. I still like iButtons and SecureIDs when someone else is paying the bill... (by coder 08 Nov 2009 19:36) I forgot to mention the poor man's secure banking I recommend to less technical family and friends: I burn them a live Ubuntu or Knoppix CD! (by coder 08 Nov 2009 19:42) > 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... http://www.zurich.ibm.com/ztic/ Indeed, deployment is expensive, but not outrageously, especially if any 2FA has already been considered. Ztic adds an SSL server on the USB stick, let the server inspect & display results directly from the SSL stream, and register this (almost) painlessly as a proxy for the regular host browser. Since it lurks as a hop within the SSL stream, it does not need to change infrastucture substantially, unlike, say SMS-assisted secondary channels would. The user still interacts with the browser, but is able to cancel or confirm responses on hardware out of reach for any Trojan. (There is a secondary mode for mTAN-like usage, by the way.) There are much more expensive snake-oil devices, usually USB sticks with dedicated browsers (which are sold as being able to execute securely, without being compromised, even on infected hosts; no comment). These seem to be marketed to banks in continental Europe in waves. Deployment costs are similar to smarter devices, obviously, even if the ones carrying code for the PC don't provide the security of an out-of reach keystore. Disclaimer: I'm tangentially involved with development (same group). (by tvi 09 Nov 2009 03:17) Thanks for your interesting article. I wish one of the Canadian banks would do any sort of two-factor authentication, let alone an out-of-band solution. I don't think the Man-in-the-middle threat is as great as the plain vanilla keylogging threat. For a cool out-of-band TFA solution, check out PhoneFactor.com. (I've got absolutely no affiliation - I've just been researching solutions and theirs looks very promising.) They've signed up a US bank and it has the potential to have you authorize each transaction using a registered cell or landline phone. This is the slickest and least expensive solution I've seen yet. Dan (by Dan Frederick 17 Nov 2009 01:39) Banking Security a must! Yes a keyfob is a must have. I bank with a FDIC insured bank whom issues keyfobs to use in combo with your username and p*ssw*rd. > PhoneFactor.com I have deployed PhoneFactor in a test enviornment - I am impressed but not satisfied. (by brian 17 Nov 2009 03:00) Card Reader works My Bank in the UK sent all it customers a card reader that reads the chip on your Debit card or credit card, whichever one you chose to register with the reader. This means that whenever you are making a transaction to a new recipient or a large transaction or setting up a new payment mandate then you have to put your card into the reader, enter your PIN and then type in a number supplied on screen. Then you type back into the PC the number generated by the card reader. This means that not only do you have to have the card reader and the card that you registered you have to have your PIN. These are then used to generate a response to the bank generated security number. See http://www.smile.co.uk/servlet/ContentServer?c=Page&pagename=Smile%2FPage%2FsmView&cid=1228376874183 or go to www.smile.co.uk and select "security" then "card reader" (by Bob Robinson 17 Nov 2009 06:32) One possible drawback to this system is that multiple institutions use the card reader. I use the same card reader with both Nationwide bank and HSBC in the UK. The calculation to create the number could be discovered, and a bot could emulate the transaction. (by Peter Merchant 21 Nov 2009 03:42) Add your comment... Note: all comments require an email address to send a confirmation to verify that it was posted by a person and not a spambot. The comment won't be visible until you click the link in the confirmation. Unless you check the box below, which almost nobody does, your email won't be displayed, and I won't use it for other purposes.   Name: Email: you@wherever (required, for confirmation) Title: (optional) Comments: Show my Email address Save my Name and Email for next time

Topics Copyright Law - 29 Email - 228 ICANN - 127 Internet - 73 Money - 31 Security - 3 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. 25 days ago A keen grasp of the obvious Italian Apple Cake 583 days ago Related sites Coalition Against Unsolicited Commercial E-mail Network Abuse Clearinghouse

© 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.