What are the best practices for securely storing sensitive data on mobile devices? Compare the secure storage options available on iOS and Android.

Question

Accepted Answer

Secure data storage on mobile devices is fundamental to application security because phones are frequently lost, stolen, or shared. The principle is to store the minimum amount of sensitive data on the device, encrypt what must be stored, and use platform-provided secure storage mechanisms rather than implementing custom solutions.

On iOS, the Keychain is the primary secure storage mechanism. It is a hardware-backed encrypted database that stores small pieces of sensitive data like passwords, authentication tokens, certificates, and encryption keys. The Keychain uses the Secure Enclave on devices that have one, providing hardware-level protection that prevents data extraction even if the device is jailbroken. Keychain items can be configured with access control policies that require biometric authentication or device passcode before the data is released. You can also specify accessibility levels that control when data is available, such as only when the device is unlocked or even after the first unlock.

On Android, the Keystore system provides similar hardware-backed key storage. The Android Keystore generates and stores cryptographic keys in a hardware security module or Trusted Execution Environment, depending on the device. These keys can encrypt and decrypt data but never leave the secure hardware. For storing sensitive values, EncryptedSharedPreferences wraps the standard SharedPreferences with AES encryption using keys managed by the Keystore. For larger data, the EncryptedFile class provides transparent file encryption. Like iOS, Android supports biometric-bound keys that require user authentication before use.

Beyond the platform-specific mechanisms, several universal best practices apply. Never store sensitive data in plain text, including in SharedPreferences, UserDefaults, plist files, or SQLite databases without encryption. These storage mechanisms are easily readable on rooted or jailbroken devices and can be extracted from device backups. Authentication tokens should have expiration times and be refreshed regularly. When a user logs out, all sensitive data including cached tokens, session data, and personal information should be deleted from all storage locations.

For data that must persist in a database, such as user content or cached API responses, use SQLCipher on Android or encrypted Core Data stores on iOS. These provide full database encryption with keys managed by the platform secure storage. The encryption is transparent to the application layer, so queries and data access work normally while the data on disk is fully encrypted.

Network responses containing sensitive data should not be cached by the HTTP layer. Configure URL sessions and OkHttp clients to disable caching for sensitive endpoints. Also be aware that the operating system may take screenshots of your app for the task switcher, potentially capturing sensitive information. Implement view obscuring in applicationWillResignActive on iOS or onPause on Android to replace the screen content with a placeholder when the app moves to the background.

I also recommend implementing data classification early in the project. Categorize data into sensitivity levels: public, internal, confidential, and restricted. Each level maps to a storage strategy. Public data can live in standard storage. Internal data is encrypted at rest. Confidential data uses platform secure storage with device authentication. Restricted data like payment credentials should ideally not be stored locally at all, relying instead on tokenization services. This classification prevents ad hoc security decisions and ensures consistent protection across the application.