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?

craq
  • 384
  • 4
  • 12

1 Answers1

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! :)

Lie Ryan
  • 31,279
  • 6
  • 69
  • 93
llorrac
  • 324
  • 1
  • 7
  • 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 04 '17 at 06: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 04 '17 at 06: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 04 '17 at 06:57
  • Also, have I understood correctly that you're saying that telephone calls are end-to-end encrypted? What about interception by StingRay-type devices en route to my telco? – craq Aug 04 '17 at 06: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 04 '17 at 08: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 04 '17 at 08:10
  • @llorac why would you say that PINs to access the account don't need to be encrypted? I would've thought that secure practice would require them to be stored encrypted, and unencrypted only during the verification procedure. (Possibly even better would be if the employee entered the PIN and received a pass/fail message, so that they can't look up PINs for arbitrary customers, or to use one of the automated services I mentioned in the question... Which still wouldn't be as secure as a password for online banking.) – craq Aug 05 '17 at 04:51