Mobile Device Security: Storage of data in a mobile application - Security Analysis and Defense

When dealing with mobile applications, you often store data, configurations, and assets client-side. As a result, client-side protection of data becomes very important. 

• You should never assume that physical access will be properly restricted, even with mobile device management (MDM). 
• Other apps and services on the mobile device may be able to read the file system and local databases, especially if users are not careful with what permissions they grant applications they install.

Android, iOS, and other modern mobile operating systems provide many methods to simplify data storage and file management. However, the common mechanisms are not inherently designed for secure storage. 

1. Using a storage method like iOS’s NSDefaults or a SQLite database is not appropriate for credentials and other secrets. They are also not appropriate for storing corporate or personal data, HIPAA, PCI or PI data according to Information Security policy IS-15 System and Communications Protection. 
2. All sensitive and highly-sensitive data must be protected.
   

Ways to expose data

While it is possible to restrict your application to run on a device with a profile that mandates encryption and lock screen, this does not mean your data will be protected. Below are ways store data can be exposed:

•  Syncing data to a cloud service
•  Backup to the cloud, desktop
• Transfer to a new device which has not been properly secured yet
• Reverse engineering / forensic analysis (Refer to Module 2 in this training)
• Storage in a file system location or database accessible to other applications
•  Export features which allow data to be stored or copied in unexpected ways
• Keyboard cache may expose names, project names, or other uncommon words
  

Impact

Let's explore some of the risks and issues around storage of data in a mobile application. When data on the client-application is not properly segmented and restricted, it could be read by unauthorized users and other applications/services. This could result in a data loss and a loss of competitive edge.

Storing data locally introduces unnecessary risk even if all security controls are in place because there is still the risk of a hack of the operating system or another app, or even physical theft.

Securing Data

The best way to secure data is to not hold on to it in the first place. Note that “temporary” storage or local caching may not be so temporary without you taking steps to actively delete and overwrite the data.


What are the options for securely storing data?

Data stored locally should be protected in multiple ways, providing defense in depth. While this includes things like encryption and access control, there are often other considerations.
For example, you may use a method or library to store videos or images that defaults to storing the media in a globally accessible location like the iOS camera roll; instead, it is better to store the data in a storage location sand-boxed to your application, so it is not easily accessible by services or other applications.


What about storing credentials?

Store credentials in an encrypted storage mechanism like KeyChain. An app could always be reversed engineered or the phone itself could be subjected to forensic analysis tools or malware revealing the credentials that are stored locally.

Defense

To minimize the risk and avoid a data loss through your mobile application, you will need to build in protection. To protect the data, it is important to understand what functions are available to secure the data and restrict access in the app.

To stay proactive against data exfiltration, follow security best practices described below.

Know where you are storing data and don't allow deprecated feature 

1. Minimize data store locally. 
2. Do not store data outside of app sandbox
3. Ensure you understand any persistence or temporary storage which can be accessed by other apps.  
4. Deprecate functionality and support for older deices which cannot support acceptable secure storage.
5. Implement server side protection similar to an web application
   
6. Limit data exposure
7. Always rely on updated cryptography.
   

Use case reference:

Starbucks developers chose to store the actual user’s password in plaintext to make it more convenient for users, so that they would not need to enter it all the time.
They could have assigned a long lived token instead. In this case, from an unencrypted phone it would be possible to extract this plain text information from a simple backup tool.

Insecure Coding Practices:

• Customer credentials were stored in plain-text in the application
• User activity, such as GPS locations over time, was also stored in plain text 
  

Evan Schuman: Starbucks caught storing mobile passwords in clear text

Key Takeaways

1. Anytime you store credentials, PI, or highly-sensitive information locally without protection you are putting stored data at risk.
2. Avoid storing data locally when possible and use a system appropriate encryption method to protect locally stored data.
3.  Never store plain-text credentials.
   

-------===========--------