1. PINs and passwords should not be easily guessable and weak credentials should be disallowed; however, users should not be forced to change passwords on a regular basis.

2. Multi-factor authentication before performing financial or other sensitive functions is strongly encouraged.

3. Smartphone authenticator apps should be used for sending one-time passwords rather than SMS due to the possibility of SS7 hijacking and other insecurities.

4. If biometric information is used for authentication, it must be stored with appropriate security measures such as encrypted in the Android Keystore or with the use of trusted hardware.

1. Mobile devices should securely store confidential information, for example by using the Android KeyStore framework.

2. Trusted hardware should be used for the storage of sensitive information if it is available on client smartphones.

3. Avoid storing information in external storage and if it is done, ensure that strong input validation is performed prior to using this data.

4. Delete confidential data from caches and memory after it is used and avoid general exposure of information (e.g., placing the secret key on the stack). Assure the clean-up of memory prior to the application exiting.

5. Restrict data shared with other applications through fine-grained permissions. Minimized the number of permissions requested by the app and ensure that the permissions correlate to functionality required for the app to work.

6. Do not hard-code sensitive information such as passwords or keys into the application source code.

7. Validate any input coming from the client that is to be stored in databases to avoid SQL injection attacks.

1. The safest devices for performing financial transactions on are ones that have not been "jailbroken" or "rooted", as it can be difficult or impossible to assess the security of the underlying operating system when it has been replaced or exploited. Applications should thus use the mobile platform services to determine that they and the underlying platform have not been modified.

2. Remove any extraneous code that might have been added to the application during development, such as features that are not designed for the device platforms that the app is to be deployed upon or developer/debug features to reduce the attack surface of the deployed production code.

3. On the server-side, determine whether the app is running in a high integrity state through signature validation or hashing over the app or certain program function blocks.

Template For Mobile Application Security Best Practices

The focus here is on general best practices and not specific individual technologies except where explicitly discussed. For this template, we draw on recent works on examining digital financial services applications from the standpoint of the mobile money application space, including the GSMA study on mobile money app security best practices, the ENISA smartphone secure development guidelines, and a mobile payment applications security framework developed by the State Bank of Pakistan.

This template can also be used also as input to an app security policy by DFS Providers.

The template strictly considers the mobile application on the device unless stated otherwise, and subsections describing recommendations deal with various aspects of the operation or underlying policy relating the mobile application. The focus is primarily on Android applications given their large market share, though many recommendations are applicable across mobile operating systems. Privacy is also an important factor to consider, but these recommendations focus on security.

1. Develop applications according to industry-accepted secure coding practices and standards.

2. Assure a means of securely updating applications and assure that all dependent libraries and modules are secure; provide updates for these when required.

3. Have code independently assessed and tested by internal or external code review teams.

1. Apps should be making use of standardised cryptographic libraries and for communication with back-end services, should use end-to-end encryption with standardized protocols, specifically TLS. The minimum recommended version of TLS that should be used is version 1.2.

2. TLS certificates should not be expired and should present strong cipher suites, specifically AES-128 encryption and SHA-256 for hashing. Authenticated encryption modes of operation such as GCM are encouraged.

3. Limit the lifetime of issued certificates to 825 days in accordance with the CA/Browser Forum best practices.

4. Assure the trustworthiness of the certificate authority and consider a contingency plan for if the CA is no longer trusted.

5. Ensure the configuration of TLS is performed in a secure fashion and avoid misconfiguration issues that could result in failure to authenticate or poor algorithm selection.

6. Certificate pinning is recommended to prevent replacement of certificates.

7. Client devices must ensure that they correctly validate server certificates.