Mobile Application Coding Guidelines

The purpose of this section is to provide application developers guidelines on how to build secure mobile
applications, given the differences in security threat between applications running on a typical desktop as
compared to those running on a mobile device (such as tablets or cell phones).
Using the guidance provided here, developers should code their applications to mitigate these malicious
attacks. While more general coding guidelines should still be followed as applicable, this page lists
additional considerations and/or modifications to common guidelines and is written using the best
knowledge available at this time.

Authentication and Password Management

This is a set of controls used to verify the identity of a user, or other entity, interacting with the software,
and also to ensure that applications handle the management of passwords in a secure fashion.

a. Instances where the mobile application requires a user to create a password or PIN (say for offline
access), the application should never use a PIN but enforce a password which follows a strong
password policy.
b. Mobile devices may offer the possibility of using password patterns which are never to be utilized
in place of passwords as sufficient entropy cannot be ensured and they are easily vulnerable to
smudge-attacks.
c. Mobile devices may also offer the possibility of using biometric input to perform authentication
which should never be used due to issues with false positives/negatives, among others.
d. Wipe/clear memory locations holding passwords directly after their hashes are calculated.
e. Based on risk assessment of the mobile application, consider utilizing two-factor authentication.
f. For device authentication, avoid solely using any device-provided identifier (like UID or MAC
address) to identify the device, but rather leverage identifiers specific to the application as well as
the device (which ideally would not be reversible). For instance, create an app-unique “device-
factor” during the application install or registration (such as a hashed value which is based off of
a combination of the length of the application package file itself, as well as the current date/time,
the version of the OS which is in use, and a randomly generated number). In this manner the
device could be identified (as no two devices should ever generate the same “device-factor” based
on these inputs) without revealing anything sensitive. This app-unique device-factor can be used
with user authentication to create a session or used as part of an encryption key.
g. In scenarios where offline access to data is needed, add an intentional X second delay to the
password entry process after each unsuccessful entry attempt (2 is reasonable, also consider a
value which doubles after each incorrect attempt).
h. In scenarios where offline access to data is needed, perform an account/application lockout and/or
application data wipe after X number of invalid password attempts (10 for example).
i. When utilizing a hashing algorithm, use only a NIST approved standard such as SHA-2 or an
algorithm/library.
j. Salt passwords on the server-side, whenever possible. The length of the salt should at least be
equal to, if not bigger than the length of the message digest value that the hashing algorithm will
generate.
k. Salts should be sufficiently random (usually requiring them to be stored) or may be generated by
pulling constant and unique values off of the system (by using the MAC address of the host for
example or a device-factor; see 3.1.2.g.). Highly randomized salts should be obtained via the use
of a Cryptographically Secure Pseudorandom Number Generator (CSPRNG). When generating
seed values for salt generation on mobile devices, ensure the use of fairly unpredictable values
(for example, by using the x,y,z magnetometer and/or temperature values) and store the salt
within space available to the application.
l. Provide feedback to users on the strength of passwords during their creation.
m. Based on a risk evaluation, consider adding context information (such as IP location, etc…) during
authentication processes in order to perform Login Anomaly Detection.
 n. Instead of passwords, use industry standard authorization tokens (which expire as frequently as
practicable) which can be securely stored on the device (as per the OAuth model) and which are
time bounded to the specific service, as well as revocable (if possible server side).
o. Integrate a CAPTCHA solution whenever doing so would improve functionality/security without
inconveniencing the user experience too greatly (such as during new user registrations, posting of
user comments, online polls, “contact us” email submission pages, etc…).
p. Ensure that separate users utilize different salts.
Code Obfuscation
This is a set of controls used to prevent reverse engineering of the code, increasing the skill level and the
time required to attack the application.

a. Abstract sensitive software within static C libraries.

b. Obfuscate all sensitive application code where feasible by running an automated code obfuscation
program using either 3rd party commercial software or open source solutions.
c. For applications containing sensitive data, implement anti-debugging techniques (e.g. prevent a
debugger from attaching to the process; android:debuggable=”false”).
d. Ensure logging is disabled as logs may be interrogated other applications with readlogs
permissions (e.g. on Android system logs are readable by any other application prior to being
rebooted).
e. So long as the architecture(s) that the application is being developed for supports it (iOS 4.3 and
above, Android 4.0 and above), Address Space Layout Randomization (ASLR) should be taken
advantage of to hide executable code which could be used to remotely exploit the application and
hinder the dumping of application’s memory.
Communication Security
This is a set of controls to help ensure the software handles the sending and receiving of information in a
secure manner.

a. Assume the provider network layer is insecure. Modern network layer attacks can decrypt
provider network encryption, and there is no guarantee a Wi-Fi network (if in-use by the mobile
device) will be appropriately encrypted.
b. Ensure the application actually and properly validates (by checking the expiration date, issuer,
subject, etc…) the server’s SSL certificate (instead of checking to see if a certificate is simply
present and/or just checking if the hash of the certificate matches). To note, there are third party
libraries to assist in this; search on “certificate pinning”.
c. The application should only communicate with and accept data from authorized domain
names/systems. It is permissible to allow application updates which will modify the list of
authorized systems and/or for authorized systems to obtain a token from an authentication server,
present a token to the client which the client will accept.
d. To protect against attacks which utilize software such as SSLStrip, implement controls to detect if
the connection is not HTTPS with every request when it is known that the connection should be
HTTPS (e.g. use JavaScript, Strict Transport Security HTTP Header, disable all HTTP traffic).
e. The UI should make it as easy as possible for the user to find out if a certificate is valid (so the
user is not totally reliant upon the application properly validating any certificates).
f. When using SSL/TLS, use certificates signed by trusted Certificate Authority (CA) providers.
Data Storage and Protection
This is a set of controls to help ensure the software handles the storing and handling of information in a
secure manner. Given that mobile devices are mobile, they have a higher likelihood of being lost or stolen
which should be taken into consideration here.

a. Only collect and disclose data which is required for business use of the application. Identify in the
design phase what data is needed, its sensitivity and whether it is appropriate to collect, store and
use each data type.
 b. 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
c. Store sensitive data on the server instead of the client-end device, whenever possible. Assume any
data written to device can be recovered.
d. Beyond the time required by the application, don’t store sensitive information on the device (e.g.
GPS/tracking).
e. Do not store temp/cached data in a world readable directory. Assume shared storage is untrusted.
f. Encrypt sensitive data when storing or caching it to non-volatile memory (using a NIST approved
encryption standard such as AES-256, 3DES, or Skipjack).
g. Use the PBKDF2 function to generate strong keys for encryption algorithms while ensuring high
entropy as much as possible. The number of iterations should be set as high as may be tolerated
for the environment (with a minimum of 1000 iterations) while maintaining acceptable
performance.
h. Sensitive data (such as encryption keys, passwords, credit card #’s, etc…) should stay in RAM for
as little time as possible.
i. Encryption keys should not remain in RAM during the instance lifecycle of the app. Instead, keys
should be generated real time for encryption/decryption as needed and discarded each time.
j. So long as the architecture(s) that the application is being developed for supports it (iOS 4.3 and
above, Android 4.0 and above), Address Space Layout Randomization (ASLR) should be taken
advantage of to limit the impact of attacks such as buffer overflows.
k. Do not store sensitive data in the keychain of iOS devices due to vulnerabilities in their
cryptographic mechanisms.
l. Ensure that sensitive data (e.g. passwords, keys etc.) are not visible in cache or logs.
m. Never store any passwords in clear text within the native application itself nor on the browser (e.g.
save password feature on the browser).
n. When displaying sensitive information (such as full account numbers), ensure that the sensitive
information is cleared from memory (such as from the webView) when no longer
needed/displayed.
o. Do not store sensitive information in the form of typical strings. Instead use character arrays or
NSMutableString (iOS specific) and clear their contents after they are no longer needed. This is
because strings are typically immutable on mobile devices and reside within memory even when
assigned (pointed to) a new value.
p. Do not store sensitive data on external storage like SD cards if it can be avoided.
q. Consider restricting access to sensitive data based on contextual information such as location (e.g.
wallet app not usable if GPS data shows phone is outside Europe, car key not usable unless within
100m of car etc...).
r. Use non-persistent identifiers which are not shared with other apps wherever possible - e.g. do not
use the device ID number as an identifier, use a randomly generated number instead.
s. Make use of remote wipe and kill switch APIs to remove sensitive information from the device in
the event of theft or loss.
t. Use a time based (expiry) type of control which will wipe sensitive data from the mobile device
once the application has not communicated with its servers for a given period of time.
u. Automatic application shutdown and/or lockout after X minutes of inactivity (e.g. 5 mins of
inactivity).
v. Avoid cached application snapshots in iOS: iOS can capture and store screen captures and store
them as images when an application suspends. To avoid any sensitive data getting captured, use
one or both of the following options: 1. Use the ‘willEnterBackground’ callback, to hide all the
sensitive data. 2. Configure the application in the info.plist file to terminate the app when pushed
to background (only use if multitasking is disabled).
w. Prevent applications from being moved and/or run from external storage such as via SD cards.
x. When handling sensitive data which does not need to be presented to users (e.g. account numbers),
instead of using the actual value itself, use a token which maps to the actual value on the server-
side. This will prevent exposure of sensitive information.
Paywall Controls
This is a set of practices to ensure the application properly enforces access controls related to resources
which require payment in order to access (such as access to premium content, access to additional
functionality, access to improved support, etc…).

a. Maintain logs of access to paid-for resources in a non-repudiable format (e.g. a signed receipt sent
to a trusted server backend – with user consent) and make them securely available to the end-user
for monitoring.
b. Warn users and obtain consent for any cost implications for application behavior.
c. Secure account/pricing/billing/item information as it relates to users. If client has made any
purchases via the application for instance, we should ensure that what they bought, the size of
purchase, the quantity of the purchase, etc… should all be treated as sensitive information.
d. Use a white-list model by default for paid-for resource addressing.
e. Check for anomalous usage patterns in paid-for resource usage and trigger re- authentication. E.g.
significant change in location occurs, user-language changes, etc...
Server Controls
This is a set of practices to ensure the server side program which interfaces with the mobile application is
properly safeguarded. These controls would also apply in cases where the mobile application may be
integrating with vended solutions hosted outside of the typical network.

a. Ensure that the backend system(s) are running with a hardened configuration with the latest
security patches applied to the OS, Web Server and other application components.
b. Ensure adequate logs are retained on the backend in order to detect and respond to incidents and
perform forensics (within the limits of data protection law).
c. Employ rate limiting and throttling on a per-user/IP basis (if user identification is available) to
reduce the risk from DoS type of attacks.
d. Carry out a specific check of your code for any sensitive data unintentionally transferred between
the mobile application and the back-end servers, and other external interfaces (e.g. is location or
other information included transmissions?).
e. Ensure the server rejects all unencrypted requests which it knows should always arrive encrypted.
Session Management
This is a set of controls to help ensure mobile applications handle sessions in a secure manner.

a. Perform a check at the start of each activity/screen to see if the user is in a logged in state and if
not, switch to the login state.
b. When an application’s session is timed out, the application should discard and clear all memory
associated with the user data, and any master keys used to decrypt the data.
c. Session tokens should be revocable (particularly on the server side).
d. Use lower timeout values to invalidate expired sessions (in contrast to the typical timeout values
on traditional (non-mobile) applications).
Use of 3rd Party Libraries/Code
This is a set of practices to ensure the application integrates securely with code produced from outside
parties.

a. Vet the security/authenticity of any third party code/libraries used in your mobile application (e.g.
making sure they come from a reliable source, will continue to be supported, contain no
backdoors) and ensure that adequate internal approval is obtained to use the code/library.
b. Track all third party frameworks/API’s used in the mobile application for security patches and
perform upgrades as they are released.
c. Pay particular attention to validating all data received from and sent to non-trusted third party apps
(e.g. ad network software) before incorporating their use into an application.
Mobile Application Provisioning/Distribution/Testing
This is a set of controls to ensure that software is tested and released relatively free of vulnerabilities, that
there are mechanisms to report new security issues if they are found, and also that the software has been
designed to accept patches in order to address potential security issues.

a. Design & distribute applications to allow updates for security patches.

b. Provide & advertise feedback channels for users to report security problems with applications
(such as a [email protected] email address).
c. Ensure that older versions of applications which contain security issues and are no longer
supported are removed from app-stores/app-repositories.
d. Periodically test all backend services (Web Services/REST) which interact with a mobile
application as well as the application itself for vulnerabilities using enterprise approved automatic
or manual testing tools (including internal code reviews).
e. Based on risk assessment of the application, have the application go through Security Assessment
for a review of security vulnerabilities following the Team’s internal security testing of the
application.
f. Utilize the Enterprise provisioning process (e.g. IDM) to request and approve access for users on
the mobile application.
g. Ensure the application is sufficiently obfuscated prior to release by conducting tests which attempt
to reverse engineer the obfuscated application.
h. Distribute applications via an app-store type of interface (when appropriate) as many app-stores
monitor applications for insecure code which we may benefit from.
i. Digitally sign applications using a code signing certificate obtained via a trusted Certificate
Authority (CA).