4

The fallback for my online banking login at multiple banks is telephone banking. On the phone I can make payments, but I can also reset passwords, and several other critical security functions. Usually they authenticate me by asking relatively trivial questions, along the lines of security questions. Security questions aren't good security practice for website logins, so it seems strange that they are considered secure enough for telephone banking.

Apart from weak authentication, as far as I know, telephone calls are not encrypted. Beyond eavesdropping (which I guess is like shoulder-surfing), I imagine that it is possible for someone to tap into the call (passive MITM) and record the answers to my security questions or my PIN. Recently, I've noticed that I've been passed to an automated authentication service, but otherwise there is necessarily a MITM as the bank employee has to verify my answers/PIN manually. Not only does this mean divulging sensitive information to the employee, it implies that the data might be stored unencrypted.

So, my first question would be whether my understanding is correct, that telephone banking is less secure than online banking? If so, then why is it still so widely used, and even used as a fallback to online banking?

3

This is a great question.

The TLDR is; Yes, Call Centers are generally less secure than online payments. The reason for this is because of the inherent human factor in a call center - e.g. saving payment card details into notepad to process later because the payment service is down (seriously!!!).

But, there are a couple of things to address here, 1. Payment security and 2. Call security.

To start with 2. Calls are encrypted both on their way to the bank from your Telco's PBX, and again once they hit the banks DMZ, with a thing called an SBC (Session Border Controller). This has been standard since the proliferation of VoIP tech in the enterprise environment. That said, the quality of said encryption isn't great (Base64??) and relies on an assumption that both your telco and the banks telephony team are applying patches to their kit, and upgrading it when needed.

On 1, the payments / banking industry has been at the forefront of understanding the importance of getting this sh*t right for a long time because it is such a huge risk for them.

The standard for secure payments processes / infrastructure / architecture is called PCI DSS. PCI DSS was developed specifically to provide consumers like us better security when making payments. All call centers including banks, must adhere to its standards. This also applies for any other payment "endpoint" such as in store or online payments.

There are different levels of PCI compliance based on how many payments you are processing each year. Even the lowest requires 4 random audits to be conducted each year for an organisation to retain their compliance certificate.

In fact PCI DSS is almost an industry of its own these days, with companies building infrastructure and payment services to take organisations payment services "out of scope" of PCI DSS by owning all the risk.

To answer your question specifically, some of the key things outlined by PCI DSS are:

  1. Never storing card data in plain text at rest - Tokenisation is used to overcome this.
  2. Never storing card verification ID's like CVV or Pin - Never ever
  3. Using the principle of least privilege
    • For access to network services
    • For access to payment GUI's (call center agents)
    • For access to call recordings for QA purposes
  4. Ensuring transmission of cardholder data across public networks is encrypted - With standards like SSL / TLS
  5. DTMF Masking - so that if you do punch in your card number from your keypad, all the beeps are monotone

I don't have enough rep to post more than 2 links, but for a better overview of what's required for telephone based payments, check out this blog post.

So, banks and call centers may store some of your payment card information at rest, as long as it is tokenised, and stored in a walled off PCI compliant network. Further, you will have basic encryption provided at the call being made, and again inside the banks telephony network, plus DTMF masking during any keypad payments.

In summary, with these standards and practices, you are more secure from a technology perspective when paying with an automated service than when you are talking to a human!

Sorry for the long post! :)

  • I'm glad you included DTMF masking - I attended a VOIP workshop and the instructor suggested that many companies claim to be PCI compliant, but the VOIP logs contain the DTMF events. – JonRB Aug 4 '17 at 6:25
  • A third party to whom you have provided your card details for multiple payments may tokenise them, but your bank can't. They need to have your actual card details. They encrypt them at rest; they don't tokenise them. – Mike Scott Aug 4 '17 at 6:50
  • Thanks for an in-depth answer. You seem mostly to address call centers for merchants where I might give them my credit card details in order to buy something. Calling my bank directly seems to be slightly different, but I'm having difficulty pinning down exactly how, so maybe you're right that they are just another endpoint using the same standards. Perhaps one difference is that banks do store verification IDs like PINs and answers to security questions? – craq Aug 4 '17 at 6:57
  • 1
    Hey @craq. I guess you're right, my response is kinda focused on broader compliance as it relates to card data. That said, Banks should tokenise / encrypt your card data at rest. Mike Scott mentioned that it's encrypted, but to my knowledge it is not 100% one way or the other. I'm not sure if you mean PIN numbers for a card or Pins to access your account? The former should be stored in the same manner as card numbers, the later, I believe does not need to be encrypted. Again the weakest point in that chain is the human interaction point. – llorrac Aug 4 '17 at 8:04
  • 2
    Re call encryption. No, calls are only encrypted from the Telco's PBX. Hence, still susceptible to MITM from a Stingray device :) – llorrac Aug 4 '17 at 8:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.