Building upon the foundational security principles of architecture, design, and threat modeling discussed earlier, the next critical aspect is ensuring robust data storage and privacy measures to protect user information from unauthorized access and breaches
This stage focuses on protecting user data such as personal information, health records, financial records, etc. On a smartphone, users can install multiple apps, and if the OS of that phone is misused, data can be exposed to other apps. User data can be leaked and uploaded to cloud storage, backups, or keyboard caches. One key aspect of mobile devices is that they are stolen or lost more frequently, increasing the likelihood of physical access. That’s why additional protections must be implemented.
User credentials, PII, cryptographic keys, and any other sensitive data should be protected using storage mechanisms provided by the system. Keychain for iOS and Keystore for Android provides much more secure storage and can be used to protect data against unauthorized access. Platform-specific practices can help minimize the risk of data leakage.
A mobile app collects different kinds of user data for processing, such as personal information, user credentials, or health records, but that data is not stored using secure storage.
Without secure system storage facilities, passwords and user information can be at risk of leakage to other malicious apps. If someone gains physical access to the device, attackers could use that user information to gain access to accounts and other services.
This attack can easily be mitigated by using system-provided, secure storage facilities, such as the iOS Keychain for iOS devices and Keystore for Android devices, to store sensitive data like user credentials and cryptographic keys more securely. Additionally, users' personal information should be encrypted using strong encryption algorithms both in storage and when transmitting it to a remote service.
Although logs are useful for debugging, any sensitive information, such as personal information, passwords, or payment details, should not be included because they can be easily accessed during debugging or through device logs, allowing attackers to retrieve sensitive data.
The mobile app logs its activities and errors. Additionally, sensitive data such as usernames, passwords, personal information, or payment details are written in logs for debugging and error-tracking purposes.
In such mobile apps, sensitive information is accessible to unauthorized users. Attackers can see these logs using different debugging tools and modify them to hide malicious activity for further use. Storing sensitive data in logs is also a violation of privacy regulations and can lead to legal consequences.
Logs should not include any sensitive data. Logs should be removed once development is complete.
All text inputs requiring users to enter sensitive data, such as passwords, credit card details, and personal information, must have the keyboard cache disabled to prevent data from being cached. Cached input can be easily accessed by other apps.
The mobile app has several text input fields that collect sensitive data, such as usernames, passwords, payment information, or other personal details. If the keyboard cache is not disabled for these text input fields, the operating system may store sensitive data in the device's keyboard cache.
In such mobile apps, sensitive data entered into text fields is stored in the device's keyboard cache. This cache is accessible to other apps, allowing them to retrieve passwords, payment details, or personal information. If attackers gain physical access to the device, they can also access this cached data.
The mobile app should disable the keyboard cache for all text input fields handling sensitive data to ensure that sensitive data is never stored in cache. Additionally, the mobile app should use secure text entry modes (e.g., obscuring characters with asterisks) to protect sensitive inputs.
When an app moves to the background, sensitive information displayed on the screen (e.g., passwords, financial details) must be hidden or cleared to prevent it from being captured in screenshots or accessed through the app switcher. Implementing features like masking views or displaying placeholder screens ensures data remains secure even when the app is not in use.
The mobile app displays sensitive information, such as passwords, financial details, or personal data, on the user interface. When the app is sent to the background (e.g., the user presses the home button or switches apps), this sensitive data remains visible and can be captured in screenshots taken by the operating system or accessed through the app switcher.
If a mobile operating system takes a screenshot of an application's last visible screen when moving it to the background and that last screen contains sensitive data, the screenshot may expose it to other apps. Since the captured screenshot is shown in the app switcher, anyone with access to the device can view that sensitive data.
The app should hide sensitive data or replace the screen with a placeholder screen (e.g., a blank or logo screen) when it moves to the background. This prevents the operating system from capturing sensitive information in screenshots. Sensitive data should also be programmatically removed from views before the app enters the background, ensuring it is not stored in memory or visible in app previews.
Locally stored data can be accessed by unauthorized individuals. Sensitive data should be fetched from a remote endpoint and only stored in memory for the duration of its use. This approach minimizes the attack surface and ensures that sensitive information is not accessible if the device is lost, stolen, or hacked.
An app stores sensitive data like tokens or users' personal information locally on the device. The stored data is unencrypted and is kept in an insecure location, making it easily accessible if the device is compromised.
If someone gains physical access to the device (lost, stolen, or hacked), they can access sensitive data stored locally without authentication. Additionally, other malicious apps installed on the device can read unprotected local files containing sensitive information. Attackers with physical access can also extract local storage data using different tools. Sensitive data stored locally might remain on the device even after the app is uninstalled.
Sensitive data should be fetched from a remote endpoint using secure communication protocols (e.g., HTTPS). It should be stored temporarily in memory and cleared immediately after use to minimize risk. The app should rely on secure tokens or session identifiers that expire after a predefined period to manage user sessions without storing sensitive information locally.
When storing data locally is necessary, it must be encrypted using strong encryption techniques, with the encryption key securely derived from a hardware-backed storage solution (e.g., Keychain on iOS or Keystore on Android). This ensures that even if the device is lost or stolen, the data remains protected. The key itself should be protected and accessible only after user authentication to prevent unauthorized access.
Unauthorized access to data can be prevented by implementing a mechanism that wipes local storage after a certain number of consecutive failed authentication attempts. This helps mitigate brute-force attacks and ensures attackers cannot repeatedly guess the user's credentials without triggering a security response.
A mobile app stores sensitive data locally for some of its functionality but does not have a mechanism to wipe local storage in case of suspicious activity.
Using different tools, an attacker can perform a brute-force attack by repeatedly attempting to log in. If there is no mechanism in place to clear local storage after multiple failed attempts, the attacker may eventually succeed in accessing sensitive data. Additionally, failing to clear sensitive information after multiple failed attempts violates data security regulations, potentially leading to penalties, fines, or reputational damage.
Local data storage should be wiped automatically after a predefined number of failed attempts to reduce the risk of brute-force attacks.
In the next part, we will explore best practices for securing mobile applications, focusing on authentication and session management requirements for iOS and Android developers.
...Loading
We have got the answers to your questions.
Join us to stay connected with the global trends and technologies
