Yesterday afternoon I found myself in the position of needing to call a national bank on the telephone in response to what turned out be a false fraud warning placed on my credit card account. Everything about the incident—from the fraud warning itself right up through the way the bank sought to resolve the problem—points to a systemic failure on the part of a huge and well-known financial institution to understand some of the most basic tenets of information security. These misapprehensions seem to be common everywhere, and not particular to the institution responsible for the story I'm about to tell. Of primary concern is the issue of trust—or in this case, rather, the lack thereof. Trust in an information security context is a two-way street, and this fact is (or should be) one of the chief goals in the design of any system which even pretends to aim at security. Unfortunately, the way security is handled over the telephone by banks and other institutions is fundamentally flawed in that there's no real reason for either a consumer or a banking institution to have any trust whatsoever in the person on the other end of the call. Furthermore, a lot of the "security" measures employed by banks aren't just terrible at proving identity—they are also potential vectors for leaking consumer information to malicious parties.
One way to arrive at the point I'd like to make is to look at online communication with a bank as an example of a somewhat more competently designed system. When you visit a Web page (like one on your bank's site) over an encrypted TLS connection, it's generally a good idea to ensure that you are actually receiving a page from the bank in question before you enter your personal information into forms. You can view the site's certificate in order to help you confirm that the page is legitimate, or you can trust your browser to warn you if something looks amiss. For its part, the bank will usually trust that you are who you claim you are after you respond successfully to a series of challenges: you must supply a correct password, perhaps correctly enter a two-factor auth code, and so on. In this scenario, you trust that you are in fact contacting your bank, and you bank trusts that you are in fact who you claim to be. It's far from a perfect system, but for the most part it works well enough.
Unfortunately, phone calls with banks don't adhere to this simple system of two-way trust, and that leads me to my story.
Yesterday I went to buy a couple of bagels at a neighborhood store. When the clerk attempted to run my card, it was rejected on three occasions. I grumbled a bit and took out another card, and the transaction finally completed successfully. Suddenly, my phone began to ring, with the call coming from a number I did not recognize. I refrained from answering the call as I always do when I have no idea who is calling me (I'm neither insane nor a masochist), took my bagels, and walked home. When I checked my voicemail, I learned that the bank which had issued the rejected card had attempted to call me because something had triggered their Fraud Protection System™. Uh oh.
Somehow my purchase of roughly $10 in a store near my home—a store which I visit quite regularly, and at which I had used this card previously—had triggered a fraud alert (let's set aside the incredible dumbness of their fraud detection algorithm for the purposes of this post). My account had been frozen, the voicemail drone informed me, and in order to reinstate my account I would need to call Fraud Prevention Services™ at the number specified.
But how was I know for sure that this call was coming from the bank? There was no way to identify with certainty that the call was not coming from a random attacker; spoofing a phone number is laughably easy for one thing, and for another a clever attacker might reasonably assume that I would simply trust the call on its face, call the number, and spill all sorts of personal information in a panicked attempt to regain access to my money. Knowing all of this, I did not call the number given to me in the voicemail, but instead called the number printed on the back of the card. This is a safer bet than calling some random number in a voicemail, so despite a lingering feeling of unease I went for it.
The bank would help me sort this issue out right away, the nice lady on the line said. She just needed to ask me some questions: What is my phone number? Where am I employed? What are the last four digits of my account number? ...and so on. The answers to these questions, I was told, would allow them to confirm my identity. There are many, many issues with the assumptions the bank is making here; below are some the issues which occurred to me instantly, without even having to put much thought into it:
- The "public information" the bank uses to identify you—your phone number, the name of your employer, the address where you lived in 1998—is public information. Anyone can usually dig up this info after about five minutes of Googling.
- The last four digits of your credit card aren't all that hard to dig up for a mildly determined attacker either. These digits are stored in the databases of every service to which you now, or have ever, subscribed. These digits are the way these services identify your payment method. Was your Yahoo! email address one of the millions that got popped a while back? Do you use that password at Netflix, which displays the last four digits of your card right on your account page? You see where this is headed.
- What about the last four digits of your social security number? See previous item.
- How do I know I'm actually speaking to someone at Foo Bank & Trust? Because I called the number on my card? Calls can probably be re-routed surreptitiously in all sorts of ways. While it's pretty unlikely, someone might for example be outside my apartment in a van with a hacked-up femtocell, running a man-in-the-middle attack on my cell phone.
- Running an MITM attack like this would be a great way to grab some hard-to-get personal information on an attack target, or even to trick the target into coughing up a full credit card number: "For your security, sir, please provide your 16-digit account number."
The list could go on and on from there.
You may at this point think I'm just being paranoid, and to a large extent you're right. It's highly unlikely that any of the above scenarios would be perpetrated on a random member of the public. It's true, however, that much of the above might pretty easily be perpetrated on you at any time, and so you should be very careful when calling a number you believe belongs to a bank, a utility, a government agency, etc.
On the institutional side, I think the case is clear for the need to find some better means of authenticating users. Some kind of two-factor auth method might be workable and convenient enough, at least as an optional method for paranoid people like me to turn to. Additionally, someone really ought to think of a way for the bank to confirm to the customer that it's in fact the desired bank on the line, and not a malicious attacker working with a call center in India to perform a massive phone-phishing scam. This is a trickier problem, and it's not immediately clear to me how it might be addressed. If trust is key in any secure system, however, it has to go in both directions. Banks would do well to remember that when their customers get ripped off, it is often the banks themselves who are left holding the (emptied) bag.