When app developers are developing a mobile application, it should be taken into account that the data with which this application operates may be of some interest to third parties. The value of this data varies widely. However, even the simplest private information, for example, the password to log in to an application, requires consideration of its protection. This is especially important in light of the spread of mobile applications in all areas of electronic services, including financial, banking, storage and transfer of personal data, and so on.
Mobile app security
The main types of attacks on the mobile application:
- The rutting of the device and the attack on the application and the algorithms used in it through external debugging tools.
- Interception of data shared over the internet. Many applications are client-server, and as a result, they share and receive large amounts of information. And although modern mobile and web development are actively completing the transition to the HTTPS communication protocol, nevertheless, you should not rely on a single line of protection in the form of a secure communication channel.
- Decompiling the application file and parsing locally stored data. This protection at the present time level lies entirely on the shoulders of the
app developers.
The specifics of developing mobile applications
There are several common points for all app developers and mobile platforms that should be followed during development.
User Code Protection
- At present, it is highly recommended to use a limit on the code length of at least 6 digits (more is possible, less is not) when using digital codes.
- Any user code should have a limited number of input attempts (for example, 5 times), then, in case of failure, the application should be automatically logged out (or completely blocked, depending on the particular application).
- If an application is protected by a user password (PIN code, fingerprint scan, graphic password, etc.), then when the application goes into the background, it should immediately display an input window for this security code, overlapping the entire screen of the application. This eliminates the possibility for the attacker to obtain private information in the event of theft of the device while the application is still running and in sleep mode.
The operation of the client-server application
- The client-server app must not alter the sensitive data in local mode. Actions that require alteration should be synchronized with the server. The exception to this rule is only a user login code, which is set personally by the user and stored in secure local storage.
- For client-server applications, it is very useful to employ limited timed sessions. This would stop the app from being “idle” in an unprotected mode if the user simply forgot to close it and left the device freely available. One of the successful examples of the implementation of this mechanism is to obtain the absolute value of time from the server after going through the user authorization procedure (the date and time should show exactly when the session becomes inactive). The date and time of the end of the session should not be generated on the device because it would reduce the security and flexibility of the application.
Additional recommendations
- App developers should disable inputting unprotected files and logging of data to the system console. Specific logs for the app developers may be present, but preferably in an encrypted form, in order to avoid third-party access to proprietary information that may be present in the logs.
- It is absolutely unacceptable to use closed-source cryptographic libraries (even if they are paid). In such solutions, you will not be able to check in any way the effectiveness of the library and also how "honest" its protection is (does it have a backdoor mechanism, or is the "protected" data not sent to any third party).
- Even though some libraries claim to offer
data protection, you should not blindly trust them. The exceptions are libraries that are time-tested and used in large projects of corporations (for example, embedded encryption in the open engine of the Realm database). In the overwhelming majority of cases, the standard mechanisms for protecting the operating system and publicly-proven cryptographic algorithms will be more than enough. App developers need to be careful with the library they use during mobile app development. They should only use the ones that guarantee user data protection.
- The application should not display sensitive user data in well-readable, bright, large fonts, except it is necessary and without a special user request. This is because the data might be read from the screen of the devices being used.
It is also worth mentioning that the protection levels applied depends on the specific application. For example, if the application is not at all client-server, does not contain any sensitive user data, and also does not operate with valuable internal algorithms, then there is no point in attaching any protection to it. If the application is focused, for example, on performing banking operations or storing user passwords, then its degree of security should be the highest.
However, the previously listed general mobile sector vulnerabilities can be easily excluded from the application. Most time, this doesn’t present additional costs if the application of the required level of protection was started in the early stages of application development by the app developers. But the implementation of post-factum protection in an already running application may well be associated with significant time and effort of app developers.