An Overview Of Securing Communication Between Customers and Companies.

Summary:

• The security of modern information systems is continuously a growing critical concern;
• The default authentication flow is poor; for example, there is often no way to verify both parties;
• We propose a simple solution, which we published on GitHub. The code for the back-end is here, and for the Android front-end is here;
• Whilst the implementation of the idea we present isn’t production ready, we certainly may develop a comprehensive solution for you;

The security of modern information systems is continuously a growing critical concern. Systems that store sensitive medical and financial information are especially vulnerable. Although IT systems have become more complicated, security is still only as strong as the weakest link in the security chain. Unfortunately, in most cases, the weakest links of any system’s security are the people who use it.

Securing The Past

Despite evolving IT systems, older communication channels are still very popular. E-mailing, text messages, and phone calls are the main parts of communication between banks and customers. Furthermore, some organizations are mixing the “old-school” and more modern communications channels, making security more complex, multilayer, and, as a result, vulnerable. A good example is the banking industry which very commonly uses Web Services, Mobile Applications, Text Messages, and Phone Calls to communicate with customers.

The Problem

Let’s imagine a scenario in which a bank customer service is calling a bank customer. To authenticate, the bank customer needs to provide correct answers to pre-defined authentication questions, e.g., Mother’s maiden name, place of birth, etc. While hard to find answers, these questions are not impossible to “crack”. In fact, an estimated ~$20 billion dollars was lost due to scam calls (!), and nearly 1 in 3 Americans admit to being a victim of a phone scam.

This, in turn, shows us how poor the default authentication flow is:

• A customer cannot verify the bank’s customer service representative.
• A customer needs to provide private information in a potentially insecure way, e.g., anybody could overhear everything we say, easily.
• In most cases, it is relatively easy to trick the potential victims to give correct responses to the most common authentication questions.

The most dangerous are points one and two. In the first case, there is a high risk of a middleman attack. In the second point, there is a risk that private information will be taken and used by attackers.

Our Solution To The Problem

Nowadays, most bank customers have secure access to bank accounts with web services or mobile applications. These may be used to authenticate communication parties who are in touch through non-secure channels, such as over a phone call. The flow is more or less the same, as you may see on the image below:

• The bank’s employee calls the bank’s customer. To specify the authentication method, the employee asks the customer how they are accessing their bank services — Bank Website or Bank Mobile Application:

a) If the customer has access to the improved security flow, then the employee asks the customer to open a contact verification service and to provide a one-time authentication code;
‍
b) If a bank customer does not have access to the improved flow, then the standard verification procedures will be used — the proposed secure authentication method will not be used;
‍

1. The customer opens the app and authenticates themselves. The service shows the customer their temporary code;
2. The customer is informed that the bank employee needs to be verified too;
3. The customer forwards the one-time code, and asks for the response;
4. The bank employee verifies the customer code;

• If the code is valid, the authentication process on the customer-side passes, and the employee goes to the 6th point;
• If the code isn’t valid, then the appropriate bank security procedures to report security incidents shall be introduced;
  ‍The bank employee obtains their verification code;

5. The bank employee passes the verification code on to the customer;

6. The customer verifies the employee’s code:

• If the code is valid, then the authentication process passed successfully for both communication parties;
• If the code isn’t valid, then the customer shall hang up and reports the security incident to the Bank;

Our Proof of Concept

They say that actions speak louder than words, and so we provided the proposed verification solution ourselves. Thanks to the technical expertise of Michał Poteralski, the solution was implemented for Android mobile devices, and we used a popular Python framework, Django, as the back-end. The application allows for both authenticating requests (requesting authentication of the other party) and responding to the authentication requests. To keep things simple, and rather than to re-implement the obvious, we are showcasing only the basic authentication.

The Android Mobile App. The Front-end.

The Android mobile application needs to provide user registration and authentication service to the Web Service. For user authentication, we used a JWT token. Because of security reasons, applications should always authenticate with the web service. To improve the UX, we may easily implement biometric authentication, such as fingerprint scanning, or scanning one’s face.

Django. The Back-end.

To get up, and running, we deployed our Django back-end using the AWS Elastic Beanstalk service. Why not Bottle, Flask or FastAPI? Django is a batteries-included Python framework for creating back-ends. It is batteries included, which was the deciding factor. Naturally, you may use whatever fits your organization best: ASP.NET, Nest.js, Spring, Phoenix, and others.

As a side-note, we simplified the token generation process, as well. To provide a fully random token, an external service such as AWS KMS can be used, or you can use a (true) random number generator.

Summary

The Proof of Concept we published is an example implementation of securing the fundamental communication avenue between the trusted institutions, such as banks, and customers & clients. The need for trust between the two parties is the highest priority.

The code we have for you is freely available for you, and your team, and we used a permissive AGPL v3 license, so that you, and your engineers may look at it, and build on that foundation. Should you need experienced developers to do that for you, or the expertise of the author, Michał Poteralski, contact us here.

Originally published at https://www.itmagination.com.