Mobile App Secure Development Guidelines and Mobile App Platform Requirements were compiled on the request of the Ministry of Economic Affairs and Communications and for the description of activities specified in the Government of the Republic’s action programme (ratified in 2011). The aforementioned activities include developing security requirements for e-services used in mobile devices and specifying requirements for operating system and browser interoperability.
The purpose of this document is to provide general requirements and guidelines to be followed when developing applications for mobile devices, both for public procurement and for private business purposes. The development guidelines are meant as a tool to be used by both the contracting entity and the developer.
This document touches several topics connected with mobile app development and describes a set of guidelines that must be considered during planning and development for the end result to be a secure and usable mobile app.
Mobile App Secure Development Guidelines were developed in the scope of the project “Nutikaitse 2017”. It was launched in November 2013 by the cooperation of the public and private sectors. Its purpose is to contribute to the secure running and use of mobile e-services and solutions in times when computer use has moved to people’s pockets.
The project is coordinated by the Look@World Foundation. All connected parties of the cooperation agreement wish to raise security awareness and skills of mobile device users, developers, and sellers. By doing so, to further easy access to secure and usable softwre.
Attention must be given to user authentication. It also has to be ensured that the user session of a user authenticated in a mobile app would be protected and impossible to take over.
In secure handling of passwords, it must be considered that in addition to security measures employed in app development, much is dependent on how users protect their own devices, i.e. on the screen lock and PIN codes chosen, on biometrical authentication methods chosen, on using different passwords for various services, and on how users physically protect their devices to keep them from falling into strangers’ hands or to keep them from getting lost.
The strength of the authentication mechanism used to enter an application must be contingent on the sensitivity of the data the application processes (e.g. personal information, financial operations). The combination of the application’s own username and password is the weakest authentication mechanism. When users choose their passwords, it is best to give instant feedback on the strength of the inserted password.
If necessary, 2 factor authentication should be considered, i.e. adding additional security measures to the authentication process, e.g. SMS verification codes, using a special key generation application or a PIN calculator. If necessary, CAPTCHA code may be added for human detection.
If using verification codes, it is advisable that the developer of the application or the client inquire from every target market’s mobile operator whether the local operators and service provider used for sending SMSs have corresponding service contracts to ensure that SMSs containing authentication codes reach end-users.
When using delegated authentication (e.g., OAuth), one should use the latest version of the corresponding standard.
Because a mobile device may have multiple users, the identity of the user should be checked, rather than that of the device’s.
It’s worth reconsidering whether masking characters in password entry forms should be done. Leaving them visible may improve both usability and security as doing so permits people to choose more complex passwords.
Further reading: http://www.nngroup.com/articles/stop-password-masking/
A user should be able to use any Estonian alphabet character in a password.
Gestures made on the screens of mobile devices leave traces and smudges, from which it may be later possible to identify patterns or input. If necessary, security concious interfaces should be designed such that they reuse areas of interest to obfuscate previous gesture patterns.
In order to make authentication more secure, it is possible to follow context: the device’s identifier, IP-addresses, etc. If the application identifies an unanticipated change in the context (e.g. a change in the IP-address location country), it is advisable to implement additional authentication measures.
Passwords should never be stored in plain text. If it becomes necessary to store passwords on the device itself, they must be stored using secure storage mechanisms provided by the host platform.
However, authorization tokens should be preferred to storing passwords, as those won’t leak the original password in case of a security breach and can be revoked independently.
After the user has been initially identified in the application, authorization tokens should be used instead of the password. These must be securely saved on the device, they must have a predetermined expiration date, and they must also be possible to invalidate remotely by the backend server. It must be ensured that authorization tokens would expire as frequently as is practical (also dependant on the purpose of the application).
Any used session identifier should be such that it can’t be guessed, constructed nor derived from other known identifiers.
It has to be taken into account that the output of pseudorandom number generators (PRNG) depends highly on the entropy of the initial seed value and the quality of the PRNG itself. Make sure to use a cryptographically secure random number generator provided by the platform for session identifiers.
A user should have the option of changing passwords within the app. Each password picked by the user must be checked for sufficient complexity (including the complexity of visual passwords).
Consent for transmitting personally identifiable information, incl. identification information, should be stored and retrievable later.
The Mobile-ID confirmation code shown for authenticating or digital signatures should be positioned so it’s visible clearly and remain visible until the authentication is complete. The ability to compare the code shown in a mobile app with the one shown on the Mobile-ID SIM-card application before entering one’s PIN is required by the Mobile-ID standard and permits the user to confirm whether they’re signin in to the service they’re expecting. We shouldn’t cultivate a habit of ignoring it.
It may be convenient for the user if the mobile app notifies them of the expiration of their Mobile-ID certificates should those, for example, expire in the next 30 days.
Informational and error messages shown during the use of Mobile-ID should be made understandable to the user and shouldn’t contain excessively technical details.
User session lifecycle events, such as signing in, signing out and so on, should be logged.
A user must have a way to sign ouf of the app and revoke all authorization tokens. That includes ending all authenticated sessions.
In order to minimize the risk of data leakage – including personal data leakage – from a device to third parties, corresponding risk minimization measures must be deliberated and employed.
Classify data storage according to sensitivity and apply controls accordingly (e.g. passwords, personal data, location, error logs, etc.). Process, store and use data according to its classification. Also, pay attention to to the security of sensitive data passed to external API calls.
For software made by or for the public sector, sensitive data should be classified with the help of IT Baseline Protection Manual.
Handling sensitive personal data, such as medical data, needs registering at the Estonian Data Protection Inspectorate (page in Estonian).
During planning it’s advised to follow the principle of least knowledge, that is to not collect more personal information than is necessary for the functioning of the app. That will save having to ensure their confidentiality.
When storing data it should also be clear how long should the lifetime of any particular data be, and when can it be automatically purged from either volatile or non-volatile memory.
Location or any other sensitive personal data should not be kept in the device longer than absolutely necessary.
The whole lifecycle of a piece of data should be taken into account, starting from when it was first obtained through the network, through temporary storage on the device or memory, up to non-volatile storeage, incl. backup, and ending with deletion.
Sensitive data, especially authentication tokens and passwords, can only be stored on the device in encrypted form. When possible, save them to read-only and temper-proof areas.
When choosing a cryptographic algorithm, prefer well-known, publicly vetted algorithms (such as AES), and optimal lengths of cryptographic keys.
When storing data on the mobile device, use the crypto-APIs provided by the host platform or by any well-trusted 3rd party instead of inventing your own.
It should be assumed that any shared storage space on a device is unsafe and untrustworthy and any data stored there may be unexpectedly modified or leaked. In other words, the integrity, confidentiality and availability of that data is comproimsed.
Device RAM and temporary storage areas are possible leak channels if they’re shared with other apps. Ensure such temporary data isn’t stored in publicly readable and writable directories.
Data may leak also through non-temporary shared storage, such as the call log, address book or photo gallery. For example, a user may inadvertently share personal data through location data stored on images.
An app’s configuration file may be changed by other apps if stored on a publicly writable way. Even if the configuration lacks private information, it still often is important to withhold the integrity of it, lest it can become a attakc vector.
It’s fundamentally difficult guarantee proper removal of data from cloud services or from the device’s local storage. That should be considered as data gets stored — it may be available indefinitely.
When utilizing cryptography, an algorithm should be chosen such that it doesn’t weaken over time faster than the data loses it’s value.
For extra security a developer may add the ability for a user to delete their data remotely from devices they’ve installed the same app. While useful, it may entail new risks, so ensure strong authentication to mitigate those.
Only encrypted or hashed versions of passwords and authorization tokens must be included in regular data backup. It must be taken into consideration that the strength of any encrypting or hashing algorithm weakens over time. Thus, backup copies containing encrypted data must not be stored longer than the effective use time of the encrypting algorithm.
A mobile app should verify all input data and either inform the user of any mismatches or convert them to a suitable form.
It’s suggested to use the BDOC container format for digital signatures. Signing itself should use the newer elliptic curve (ECC) algorithms, which are compulsory since Jan 1, 2015.
When using network connections, one should remember that data transfers over the network must be through encrypted channels because not all parts of network are guaranteed to be under the control of the user or the developer of the application.
These days, a large umber of mobile apps require access to the network and backend servers to function properly. If those servers or network channels are not sufficiently secure, they can be used as attack vectors.
Data must be transmitted only over secure channels (such as SSL/TLS).
If possible, only well-known protocols and their implementations should be used. The fewer protocols are in use at once, the easier it is to ensure their robustness and security on both the receiver and sender side.
Most of the client-server use-cases today can be solved by using HTTP over SSL (HTTPS) with libraries and implementations available on all platforms.
Only security certificates signed by trustworthy certificate authorities may be used. One must also be careful in allowing self-signed security certificates. SSL chain verification in an application must not be ignored or excluded.
An SSL data channel should be created only after confirming the identities of both parties by checking their security certificates and their authenticity.
An app’s user interface should make it possible for a user to confirm the expiration date of a certificate. Generally, though, that capability should only be brought out in potential error cases.
Upon opening an app, it shouldn’t immediately start downloading large quantities of data, but instead confirm with the user if it’s okay to do so. They might be on a limited or highly priced data plan.
Sensitive personal data must not be sent over SMS, MMS or through device notifications, as those may be intercepted by third parties and the former, especially, are not encrypted.
To mitigate the risk of eavesdropping on a near field communication (NFC) transmission, encryption should be used. Even though NFC is designed for short ranges, it’s still possible to listen in meters away (up to 10m for active and 1m for passive devices).
Backend servers and their APIs should be regularly and systematically tested for security issues with a combination of automatic penetration tests and static analysis.
Backend servers should be set up with a hardened configuration: the operating system, webservers and other components should be kept up-to-date; with no unnecessary software running or plugins installed and all other network access ports closed.
Using user-based or network-based access controls may help mitigate or handle a DoS attack.
Backend servers should keep logs around for incident discovery and response. When necessary, they may also contain logs from client apps, within the law of personal data.
When creating an application, one must make sure that used third party ready-made software components are secure. One also has to ensure that related online services are secured.
Mobile apps may be given automatic access to paid functions such as phone calls, SMSs and MMSs, roaming data, NFC payments, etc. In creating such privileged access applications, possible fraudulent uses must be considered particularly carefully. Applications must be analyzed for potential weak spots and the opportunities they give to possible attackers and how to limit access to paid services.
Secure distributing of applications through official distribution channels is important. Official application stores should be preferred, for they provide the user with the updates and tend to provide additional safety checks and measures.
In order to work on a mobile device, applications tend to need a set of permissions from a user. Before requesting any particular permission, its necessity should be carefully considered. It’s safer to refrain from asking for permissions “just in case” if they are actually not necessary for the application to work. The user should have access to precise explanations why an app needs its permissions.
Passwords and other non-publically accessible information must not be kept in the source code of a mobile app. It’s fairly easy to disassemble the source code or extract other information from the executable on the device. Any binary shipped to customers must really be considered public space.
The security of an application must come from the design of the application and from the development process involving regular security tests, and not from the secrecy of the source code, security flaws, communications protocol, network address, etc. Secrets have a tendency to come out eventually.
As far as possible, the security and authenticity of all the used pre-made components should be checked. Make sure whether the components come from a reliable source and that they do not contain possible back doors and malware. This includes both libraries and source code copied from the Internet.
It is better to separate components obtained from other parties in such a way that the security holes in them would not put the application at risk. For example, integrated web views or advertisement banners should not be given access to the application’s internal functions.
Security patches and upgrades of used premade components must be followed. Whenever they appear, the application must be upgraded correspondingly.
Special attention should be given to data accepted from or sent to all unreliable third-party applications (e.g. advertising software)
As with components, data should be considered unsecure by default. Whether the structure, types, and values of the data correspond to expectations should be checked prior to using received data. Whitelisting, or only permitting suitable data, is generally more secure than blacklisting, or banning unsuitable data. In case of the latter, something unanticipated may get through.
There are two main ways to confirm the terms of service with the user:
Legally the correct approach would one of “opt-in”, as opposed to “opt-out”. That is, the user must knowlingly, and through a concious action, agree. Agreement by default, thereby through inaction, isn’t considered accepting the terms.
Users could inadvertently be identified through indicators never meant for authentication.
All requests to backend servers that make use of paid services should be authenticated.
All actions that will result in charging the user for paid services should be preceded by a warning and confirmation. That applies to large data transfers, where it’s reasonable to suggest using local Wi-Fi. People may be on limited data plan or using roaming where transfers may be expensive.
Use of services that may cause charges by the app should be monitored and minimized. For example, network transmission should be kept to a minimum.
Even though delays resulting from app stores’ approval processes must be taken into consideration, most of these stores are also capable of quickly remotely removing applications if unsecure code and risks are discovered. Thus, it is advisable to distribute apps via app stores.
It must be ensured that after an application is ready and made public upgrades can still be added to it and that at least upgrades patching security problems would regularly be available.
It is advisable to include information regarding the developer or owner of the application (including general and customer support contact information).
There should be ways for a user to notify the author of a mobile app about security issues, for example, through a dedicated email address starting with “security@”.
The code interpreter included in the application must work with minimal required rights, so that the application could not be used for actions requiring increased rights (e.g. in case some malware attempts to use the application or modified input data is entered into the application).
Code interpreters in an app should be tested against attacks and preferably be put in sandbox mode to limit.
Protection of personal data, incl. sensitive personal data, is regulated by the Personal Data Protection Act.
If a processor of personal data has not appointed a person responsible for the protection of personal data provided, the processor of personal data is required to register the processing of sensitive personal data with the Data Protection Inspectorate.
Protection of personal data, incl. sensitive personal data, is regulated by the Personal Data Protection Act.