When developing mobile applications, it should be taken into consideration that the data that this app works with, is in the interest of third parties. However, the values of these data vary greatly. Therefore, the security of the most basic data, such as the login password for the application, should be taken care of. This is crucial for apps that offer specific services, such as banks, applications for storing and transferring personal data, etc.

The most common methods of attacking mobile applications

– Attack on the application and algorithms through external troubleshooting tools.
– Interception of information shared online. Many applications are in the client-server connection, and as a result, they share and receive a large amount of data. Although modern and web development actively concludes the transition to the HTTPS communication protocol, you must not rely on a single protection line in the form of a secure communication channel.
-Reporting locally stored data. This protection is currently entirely on the shoulders of application developers.

Protecting the user code

Today, the use of six city codes in the digital code is highly recommended (of course more, no less). Each code must have a limited number of entries (example 3x). In case of unsuccessful entries, the application of such user should automatically log out or even block. This depends on the type of application. If the application is protected by a user password (PIN code, fingerprint scanning, …), then this is the first thing a user has to enter. This prevents attackers from being able to obtain private information in the event of theft of the device when applications are still running.

Client-server application

These types of applications may not contain any sensitive information in local mode. Actions that require a change must be synchronised with the server. The exception to this rule is only user login, which the user himself determines and stores in secure local memory.

It is also very useful to use limited time sessions. This prevents the application from being used in an unsafe environment if, for example, the user forgets to log out and close the application. The best way to implement this mechanism is to obtain the absolute value of the time from the server, during the user authorisation process. The date and time must show when the session becomes inactive. Also, the date and time should not be created on the device, as it would reduce the security and flexibility of the application.

Additional recommendations

Application developers must disable unprotected files and log data into the system console. There may be special developer logs, preferably in encrypted form, in order to prevent third parties from accessing proprietary information.

It is completely unacceptable to use cryptographic libraries with a closed source (even if they are paid). In such solutions, you will not be able to check the effectiveness of the library and also how its “fair” is its protection.

Although some “libraries” claim to offer data protection, you should not blindly trust them. The only exceptions are libraries that are time tested and used in large corporate projects. In the vast majority of cases, standard operating system security mechanisms and publicly-proven cryptographic algorithms will be more than sufficient. Application developers need to be careful with the library they use during application development. They should only be used by those who provide data protection for users.

The application must not display sensitive user data in well-readable, bright and large fonts unless it is required and without a specific user requirement. This is because the data can be read on the screen of the devices being used.

It should also be noted that the levels of protection applied are dependent on the specific use. For example, if the application is not on all client servers, it does not contain sensitive user data and does not work with valuable internal algorithms, then it does not make sense to overcompensate it. However, if the application is focused, for example, on performing banking operations or storing user passwords, the security level must be the highest.

However, the aforementioned general vulnerabilities of the mobile sector are easily excluded from the application. Usually, this does not entail additional costs if application developers began to use the required level of protection in the early stages of development. But the implementation of the »Post-factum protection« in an already running application can be linked to the time and effort of application developers.