• Oleksandr Kulyk, iOS Lead at Uptech Product Development Studio


• 19.01.2023 12:45 pm
#security

Leaks of sensitive user information are no news for fintech apps. The recent cyber attacks on Revolut is an illustrative case, where a data breach affected 50,000 customers worldwide. However, there are specific ways in which co-founders can strengthen the data security of their fintech apps during the development stage to increase user trust. 

Some General Knowledge About Data Security

Data security is a combination of tools, techniques, and policies taken to save digital data from fraud, unauthorized access, leaks, and modifications. These are not once-and-forever taken activities but the ones taken during the whole lifecycle of the information: from creation to destruction. The purpose of data security is threefold:     

• Confidentiality (data privacy);

• Integrity (ensuring data is trustworthy);

• Availability (ensuring there is authorized access only).

This triad is the general basis of data security. To ensure it, the company has to set up policies, controls and choose the right technologies and procedures to protect sensitive data on mobile devices. Such data includes: 

• Personally identifiable information; 

• PCI data;

• Protected health information; 

• Electronically protected information; 

• Intellectual property. 

Data Security Regulation 

Regulation is one of the pillars of data security. In its turn, regulatory compliance (which refers to organizations following local, state, federal, international and industry laws, policies, and regulations) includes data compliance. Regulatory compliance standards require using specific controls and technologies to meet the criteria. The following are some of the most common financial sector compliance regulations:

• PCI DSS is a regulation laying out the security of credit, debit, and cash transactions; 

• GDPR is the EU regulation on data protection and privacy; 

• SWIFT CSP regulates defenses against cyberattacks for financial institutions utilizing the Swift payment system;

• HIPAA compliance sets out the rules to secure sensitive patients' information in the healthcare and health insurance realm.

FinTech institutions should also comply with regional data protection laws and regulations that vary on a region-to-region basis. Some examples of such regulations are:

• FINRA – oversees US-based broker-dealer firms, registered brokers, and trade of financial assets;

• GLBA (Financial Modernization Act) – regulates the way financial institutions deal with private data of individuals; 

• CCPA – a legal regulation protecting the personal data of Californian citizens. 

Failure to comply with such regulations results in hefty fines and may cause severe legal consequences.

So what’s the big deal about data security? 

Isn’t it enough to just set up some measures and call it a day? Well, it is not as easy as putting something under the lock when it comes to the digital environment. In fact, a pretty big bunch of employees, developers, and other stakeholders have to access data to provide the service. And as more people are involved, the higher are the chances that something can go wrong. 

6 Instruments to Protect Data on Mobile Devices 

When on a device, data can exist in three different states: 

• In transfer (data is transported from server to an app); 

• Stored (data is kept on the device even when the app is not running);

• In use (data is displayed to the user in readable form).

These states are also attack vectors for hackers to access the data. Yet, certain instruments can safeguard user data even from the stakeholders who have internal access. And you need to take them at the development stage. So here they are: 

Encryption

First comes the buzzword “encryption”. This is the process of converting data into a cipher via an algorithm. There are two general types of encryption: symmetric and asymmetric. The difference between the two is all about the key.

Symmetric encryption uses a single key for encryption and decryption, so it is most commonly used when no data transfer is involved (for example, device storage encryption). When developing an app for iPhone, you can use a secured dedicated storage called Keychain. It uses the Advanced Encryption Standard symmetric algorithm, providing a necessary level of security for sensitive or personal data.

In contrast, asymmetric encryption uses two keys: a public one for encryption and a private one for decryption. This allows two parties (like the server and the app) to exchange public keys while keeping private ones private, hence the name. Thus, even if the encrypted data gets intercepted, it will disappoint the hackers, as it will make no sense. Nor will they be able to tamper with data without being compromised. An industry standard for establishing an encrypted link between a server and a client (e.g., a running app instance) is Transport Layer Security (TLS) protocol as a part of HTTPS. Using plain HTTP for data exchange introduces a plethora of possibilities for hackers.

This makes encryption a powerful tool for maintaining data confidentiality and integrity. Therefore keeping in-transfer and stored data encrypted is considered a rule of thumb.

Data Minimization

The other cornerstone of data protection is data minimization. This principle involves requesting and storing as little information as possible for user-app interaction. Indeed, the hackers won't steal the data from the device if it is not saved on the device in the first place. But sometimes, we cannot refuse to retain data entirely. Yet, we can minimize the amount of data cached on the device, which is a part of the Thin Client approach.  

The Thin Client approach means that most information is stored on the remote server, and the user app does not create any local copy of it, keeping it in device memory only while the app is running. This approach requires a stable network connection to interact with, but it allows you to eliminate a whole vector of device storage cyberattacks.

The data minimization principle applies to transferred data as well. If a user doesn't need specific personal information for a particular action, there is no need to request it from the server. E.g., Requesting a user's SSN when seeing the latest ACH transfers is unnecessary.

Access Control

Another way to protect data is to identify who can use it. Access control is the instrument that can help here. When talking about access control, we mean two processes: 

• Authentication – validation of the user’s identity;  

• Authorization – ensuring the authenticated users have access to the necessary data.  

A standard industry approach is using authentication tokens - string identifiers issued by the server in exchange for a username and password - to authorize data requests. And since we mentioned passwords, the following password hygiene best practices are essential: 

•  Setting minimum password lengths and symbol composition requirements; 

•  Encouraging users to create unique passwords;

•  Prompting for regular password changes.

While authentication and authorization are the primary control instruments, other measures and principles can alleviate the security level: 

•  Multi-Factor Authentication (MFA) - requires users to complete two or more verification factors. In most cases, it consists of a static password check and One-Time Password (OTP) received via email or phone;

•  Principle of least privilege access - grants the user the minimum access required to enable expected user-app interaction;

•  Role-based access control - allows users to access only the app functionality required by their role. 

Access control principles apply not only to users and employees but also to third-party libraries used in development. So if you are integrating an analytics tool that tracks user interaction with the app - you have to make sure such a third party doesn't have access to the values of sensitive fields presented to a user.

Adding Time Limits to Access Control

You can further enhance data security by introducing time limits to authentication tools. The tokens mentioned above are commonly issued with a fixed expiration time, after which they are no longer valid and should be refreshed. So if an app implements "remember me" re-authentication functionality for a better user experience, it is considered a better approach to store tokens instead of user credentials. This way, if user device storage gets compromised, the token may expire by the time the hackers process the obtained data. 

Another great practice is using inactivity timers – a mechanism for signing out users after a certain period of inactivity. Even if a user leaves his device unlocked and unattended with a sensitive data-filled app in the foreground, an inactivity timer will likely prevent occasional unauthorized access and protect data in use.

Keep Users Away From Root Access

When a user gets root access on their device (or, in tech slang, "jailbreak" it), they get a lot of new rights to modify the app or contact the data secured in storage. But at the same time, they expose their devices to low-level code attacks. Unfortunately, this is a risk that can hardly be avoided. Yet, it is a common practice to include the ban on using "jailbroken" devices in company policies for employees with administrator-level access.

Using Biometrics for Authentication 

Modern mobile devices provide state-of-the-art biometric authentication tools and APIs for seamless integration. The best use cases for biometrics are: 

• Quick re-authentication. Using FaceID is way less annoying than entering a password each time user opens an app that requires authentication per each session;

• Potentially destructive actions confirmation (e.g., filing a bank account closure request). Biometrics is a great way to verify that the user making such requests is the person who is authorized to perform such actions.

Conclusion 

User trust is hard to win in fintech apps. The sensitive nature of personal budget issues combined with the general anxiety about data security makes users think twice before entrusting their data to mobile apps. 

However, there are specific measures we can take on the development level to prevent any fraud or leaks.