Insecure data Storage ranks second on the OWASP’s Top 10 Mobile Security Risks list.
That is because hackers generally prefer having easy access to sensitive data that is not guarded by appropriate firewalls. This is where proper data encryption methods serve their purpose, preventing these unwanted intrusions into sensitive databases.
Thus, in summary, storing data in small, well-encrypted packets can be considered to be a line of defence against any possible threats. That is because storing your data incorrectly is equivalent to an insecure mobile phone with a ‘slide to unlock’ lock.
Insecure Data Storage
Insecure Data Storage essentially refers to data packets or data that is stored without the added protection of encryption or other firewalls. It can also refer to unintentional data leaks caused by improper application design.
This data can be accessed maliciously in two ways when it comes to mobile applications:
- If the threat agent has access to the physical device itself and
- Using Malware to gain access to sensitive data remotely.
You can largely avoid this by taking care to address all vulnerabilities during the app development phase itself. Developers should work with the assumption that threat agents can gain physical access to the device and can use Malware to access the device’s file systems remotely.
Anticipating and taking preemptive measures can go a long way in preventing Insecure Data Storage.
Am I At Risk of Insecure Data Storage?
The risk factors when it comes to Insecure data storage depend on three things, namely, the situation, the type of data and the level of security of the data storage. If, for example, someone has physical access to your mobile device, there are plenty of free tools with the help of which they can access all your sensitive data.
The risk increases significantly if sensitive data is:
- Left un-encrypted
- Encrypted with poor encryption libraries
- Stored in a shared location
- Its components, such as libraries or frameworks, used to have certain vulnerabilities that were not addressed
OWASP has determined that the most common places where data is stored insecurely are in SQLite databases, Log and Plist Files, XML data stores or Manifest files, Binary data and Cookie stores and SD cards.
Generally, data leaks are unintentional. However, there may be a lot of processes that happen in the background that a developer is not aware of.
Instances such as how the operating system caches data, log information and keystrokes apply to the development framework as well. This is why Developer awareness is key in ensuring better security in mobile apps.
It is always a good idea to model your mobile application, the OS, platforms and frameworks to better understand where their vulnerabilities lie.
If you can get a better hand on specifics such as how all of the above handle certain features such as Keyboard Press caching, Copy/Paste Buffer Caching, Logging, Handling of intermediate data, HTML 5 data storage and logging, you will know where to beef up the security of your application.
Insecure Data Storage: Threats & Impacts
As stated earlier, access to sensitive data is the end goal of any hacker. This is the worst-case scenario for users and can leave organisations open to serious reputational risk. The maliciously obtained data can also lead to the following:
- Identity Theft
- Privacy violations
- External Policy Violations (PCI)
- Material Loss
How to Prevent Insecure Data Storage?
Certain basics should be followed across the board to prevent Insecure data storage. Some of them are as simple as not leaving sensitive data encrypted, not storing sensitive data on the client side or storing sensitive data on removable SD cards.
Here are a few Android and iOS-specific best practices to follow to prevent insecure data storage in mobile applications:
iOS-Specific Best Practices
- Never store credentials on the phone’s file system. Implement forced authentication using a standard web or API login scheme. Ensure session time-outs are set to a bare minimum without hampering user experience.
- Always use a standard iOS encryption library such as CommonCrypto anytime you need to store or cache information. Whenever an additional layer of security is required for sensitive data or applications, consider using white-box cryptography solutions that overcome the vulnerabilities of common encryption libraries.
- Consider using SQLcipher for Sqlite data encryption for databases.
- For small amounts of data using Apple’s keychain API.
- For data stored in the keychain, leverage the most secure API designation, kSecAttrAccessibleWhenUnlocked and enforce the need for a stronger alphanumeric pin.
- For larger and less sensitive data, use Apple’s file protection mechanism.
- Avoid using NSUserDefaults for sensitive information, as it stores data in list files.
- Similar care should be taken when using NSManagedObjects, as all its data and entities will be stored in an unencrypted database.
- Do not rely on hardcoded encryption and decryption keys when storing sensitive data. These keys can easily be retrieved if the threat agent can decompile your app.
- Any time you are dealing with sensitive data, consider adding a second layer of encryption over what encryption mechanisms an operating system provides by default.
Android-Specific Best Practices
- Force encryption using “setStorageEncryption” for local storage of data.
- In the event data has to be stored on an SD card, you can increase the level of security via the ‘javax.crypto’ library.
- Shared preference properties should not be “MODEWORLDREDABLE” unless explicitly required in the event of information sharing between apps.
- Do not rely on hardcoded encryption and decryption keys when storing sensitive data. Hardcoded keys are ready to retrieve if the threat agents try to reverse engineer the code using a decompiler.
- As with iOS, always try to add a second layer of encryption when dealing with sensitive information.
Data leaks of any kind can have significant consequences. Insecure Data Storage can be avoided by adhering to industry-specific best practices when it comes to storing and handling sensitive data in a mobile application.
After all, security for mobile apps only exists for one purpose: to protect the data within.