Implement Secure Data Storage

    Do not store sensitive data where possible. Options to reduce the storage of user information include:

    • Transmit and display but do not persist to memory. This requires special attention as well, to ensure that an analog leak does not present itself where screenshots of the data are written to disk.
    • Store only in RAM and clear at application close (see also best practice 2.5 Securely Store Sensitive Data in RAM)

    If storing sensitive data on the device is an application requirement, you should add an additional layer of verified, third-party encryption (e.g., ) to the data as device encryption is not sufficient.

    Some options include:

    • Encrypting sensitive values in an SQLite database using SQLCipher, which encrypts the entire database using a PRAGMA key
    • The PRAGMA key can be generated at runtime when the user initially installs the app or launches it for the first time
    • The source for key generation should have sufficient entropy (i.e., avoid generating key material from easily predictable data such as username)

    Whenever you encrypt user data, aim to encrypt it using a randomly generated master key, which is also encrypted using a passphrase supplied by the user whenever data is accessed. This will prevent data from being easily recovered should an attacker extract the master key from the device. Due to the number of vulnerabilities in Apple’s data-protection APIs and keychain and the lack of device encryption on the majority of Android handsets, it is not recommended that the master key or a passphrase be stored on the device at all.

    Android and iOS implement standard crypto libraries such as AES that can be used to secure data. Remember that data encrypted with this method is only as secure as the password used to derive the key and key management. Consider the password policy, length and complexity versus user convenience, and how the encryption key is stored in memory. With root access it is possible to dump the memory of a running process and search it for encryption keys.

    Also note that using the standard cryptographic provider “AES” will often default to the less secure AES-ECB. Best practice is to specify AES-CBC or AES-GCM with a 256-bit key and a random IV generated by SecureRandom. You should also derive the key from a passphrase using the well tested PBKDF2 (Password-Based Key Derivation Function).