Toolkit: Security Checklist for Mobile App Developers -1

Rationale

Authentication and Access Control

User Authentication Must Support Adequate Authentication Strength

This is a generic requirement, and what is considered adequate will depend on the context and regulatory environment. Gartner recommends six-character alphanumeric passcodes for enterprise apps, because they provide sufficient protection against brute-force attacks. In iOS, for example, a six-character alphanumeric passcode will require 1.7 years of brute-force cracking time, whereas a four-digit PIN can be guessed in 40 minutes.

However, many banking apps, for example, offer four-digit PIN codes, and many support biometric authentication on newer devices. Gartner considers fingerprint-based user authentication to be stronger than four-digit passcodes, but no stronger than six-character alphanumeric passcodes. In this context, organizations decide to absorb residual risk in the product. In those cases, a best practice is to strongly associate the device with the mobile application. This practice is called device binding. There are various ways to perform device binding, typically involving the use of device identifiers to associate the device.

Immutable Device Identifiers, Such as Unique Device ID (UDID) and International Mobile Station Equipment Identity (IMEI), Must Not Be Used as Credentials

Although using unique device identifiers (UDIDs) to perform device binding is a best practice, it has been a common pitfall with mobile applications to use device identifiers as security credentials.³ Identifiers are not considered secret and, as such, they cannot serve as passcodes or authentication credentials. Increasingly, iOS and Android make it harder to leverage these identifiers, as well as provide alternative methods that allow identifiers for the application to use to be derived.

The Apps Shall Mutually Authenticate the User and the Server

App authentication is usually understood as the need for the mobile client to authenticate itself to the server. However, it is a common attack to tweak and republish apps, redirecting the authentication to a malicious rogue server (a command and control center). Therefore, to avoid rogue server attacks, the server must also authenticate itself to the mobile client.

The Client and Server Shall Properly Validate Transport Layer Security (TLS) or Similar Certificates

This specific recommendation assumes the app is leveraging Secure Sockets Layer (SSL)/Transport Layer Security (TLS) or another protocol. Throughout this research, we assume TLS or SSL is being used as the security transport protocol. Other protocols can be used as well, provided there is a security protocol. Whatever the protocol of choice, certificates must be validated. It is a common mistake not to validate the TLS certificates allowing man-in-the-middle attacks. (We refer to TLS, rather than the older SSL in all this research.)

By validating the certificate, the mobile client verifies that the origin of the credential is legitimate. Usually, TLS certificate validation consists of validating the signature of the certificate.

App Shall Counter Bidding-Down Attacks, Including TLS Stripping

Bidding-down attacks exploit a negotiation phase between the client and the server to weaken the defenses of the app. For example, if the server supports three types of encryption, the compromised client may pretend to only support the weakest of the three encryption types, in an attempt to break the encryption further down the road.

In general, the simplest way to prevent bidding-down attacks is to obsolete negotiation options that are vulnerable. In the specific case of TLS stripping, the bidding-down attack consists of downgrading the connection from a secure one (HTTPS) to an HTTP one. This is particularly common in web-based attacks, and also applies to WebView-based and hybrid apps. Implementing HTTP Strict Transport Security (HSTS) makes it so that HTTPS is always enforced when there is client/server communication. Features such as App Transport Security (ATS) in iOS make it increasingly easy for developers to follow this guidance.

The App Shall Implement Certificate Pinning

Pinning a certificate consists in only accepting a specific certificate, instead of verifying the general validity of the certificate. Traditional validation is still appropriate in certain situations, such as where interaction with a wide range of servers takes place (see the requirement on TLS certificate validation above).

Certificate pinning is used to prevent man-in-the-middle attacks and fraudulent certificates, and can be particularly useful for in-house-developed applications, where the identity of the server is already established and known.

Data Protection

Secret Keys and/or Passwords Must Not Be Hard-Coded in the App

This mistake is one of the most frequent in mobile application development. Secret keys, passwords, passcodes and credentials that are hard-coded in the app are can be easily stolen by attackers who download the app and reverse-engineer it. There are several alternatives to hard-coding passwords. One example is to enroll and deploy certificates that can serve as material for authentication.

Encryption Keys Shall Be Derived From Dynamically Set Values, Such as the User Passcode

To avoid hard-coding of credentials, such as secret keys, they should be derived from dynamically set values. One easy way to do this is by leveraging the user passcode, if one is used to authenticate to the app. A simple passcode will weaken the encryption key, so that the key material used should encompass other values that are independent of the key.

App-Level Encryption for Data at Rest Shall Be Used

Data at rest should be confidentiality protected. Mobile devices provide device-level encryption. Application-level encryption is provided natively by the OS or offered by the application. Entities with very high security requirements (typically verticals such as government, defense, and, depending on the context, healthcare, finance and insurance) may opt to use stand-alone encryption, while most other apps can use native mechanisms.

When using OS-native encryption mechanisms to encrypt application data, it is essential to ensure that the appropriate protection class is used. For example, when using iOS default encryption, NSFileProtectionComplete should be used. This class will keep the files encrypted when the device is locked, in case of theft or loss. In this case, the strength of encryption depends, in part, on the complexity of the device passcode. Therefore, developers should keep in mind that a weak passcode will lead to weak protection. In consumer-facing apps, the publisher of the app has no control over the strength of the passcode. However, in business-to-employee (B2E) contexts, an organization can enforce this via policy, with a requirement for passcodes of adequate complexity (Gartner recommends six-character alphanumeric passcodes).

Encryption for Data in Motion Should Be Used

Most mobile apps employ TLS as a transport security protocol, which provides encryption for data in motion. In most cases, this is sufficient as a measure for protecting data in motion. Customized solutions may use proprietary methods of encrypting data in motion through encrypted tunnels or other mechanisms.

Sensitive Data, Including Authentication Credentials, Shall Be Encrypted, Even When Stored in the Keychain

What is considered sensitive data depends on the context and the specific regulatory environment. A fundamental part of the exercise of developing a secure app will be to identify the sensitive data. That data will have to be encrypted and handled with additional care (for example, it should not be possible to export that data, as discussed in other items on the checklist).

In iOS and Android, there are keychain mechanisms, which are secure storage spaces to store credentials (such as passcodes, secret keys and certificates). In the keychain, several levels of security can be imposed natively. For example, in iOS, the setting kSecAttrAccessibleAlways allows data in the keychain to always be accessed, whereas kSecAttrAccessibleWhenUnlocked allows data in the keychain to be accessed only while the device is unlocked by the user. These settings should be selected with care and should have the maximum security possible.

However, even when these settings are set appropriately, credentials can and should be protected for high-security applications. For example, the keybag in iOS devices stores keys used to protect keychain items.

An alternative to native platform resources to protect credentials is whiteboxing (or white-box cryptography). This method consists of techniques that hide and protect sensitive application data in its own code.

The Mobile App Shall Prevent Sensitive Data From Leaking via the Autosnapshot Feature of iOS and Similar Mechanisms

To facilitate multitasking, iOS provides snapshots of apps. This allows users to view the app screen without accessing the app itself. It can be convenient when deciding which app to select and use next, but it can lead to data leakage. There is a way to obfuscate the app screen and only show the name of the application. Apps that contain sensitive data should follow this approach.

A similar feature, an overview screen, is available on Android devices; however, we have not determined whether it is possible to similarly obfuscate the screenshot.

The Mobile App Shall Not Allow Storage, Sharing or Pasting of Sensitive Data Onto Removable or Shared Media and External Resources

This recommendation will depend on the specific use case. Unless strictly necessary, it should not be possible to leverage external media that cannot be controlled and monitored. Where this can’t be avoided, the data should be stored in an encrypted form.

The App Shall Not Enable Autocomplete for Sensitive Text Input Fields

Autocomplete for sensitive text input, such as passcodes, would lead to that sensitive data being cached and prompted as choices when the user attempts to log in. This is a common pitfall with web and mobile applications, and should be avoided.

Cached Data (e.g., HTTP, Camera Images and GUI Objects) Shall Be Minimized and Deleted After Exiting the App

Especially for hybrid and mobile web apps, a major problem is how to protect cached content. There are some inbuilt ways, but the security of the method selected will typically depend on whether the user has set a complex-enough passcode on the device. It is, therefore, recommended to minimize stored data, avoid caching sensitive data and delete the data once it is no longer being used.

Sensitive Data Shall Not Be Stored in the SQLite Database on the Device; If It’s Unavoidable, a Tool Shall Be Used to Encrypt the Database

Cached data should be avoided (see previous entry). However, there are use cases and applications where this is unavoidable. The best option in those cases is storing data in SQLite and encrypting it. A tool commonly used in these cases is SQLCipher.

The Data Logged via the Keyboard Shall Not Contain Credentials, Financial Information or Other Sensitive Data

The iOS keyboard caches entries provided by users. This is done to assist with autocompletion and correction functionality. However, sensitive data is exposed to risks when cached on the device, beyond the application back end's control. Gartner recommends disable caching when sensitive data, such as credentials or financial information, is entered.

Android is similar, providing a user dictionary in which words and terms entered are logged. To disable caching, a custom keyboard can be implemented. For select devices when high security is required, the trusted user interface available in the trusted execution environment could be leveraged.⁴

The Strength of Cryptography and Key Lengths Shall Be in Accordance With FIPS 140-2-Approved Security Functions

FIPS 140-2-certified encryption is a regulatory requirement in specific industries and countries. However, it is a good practice to follow the so-called “approved security functions” in FIPS 140-2.This is because security algorithms become outdated with time. Computational power becomes strong enough to break certain shorter-keyed algorithms, and researchers sometimes uncover vulnerabilities that make algorithms breakable.