We are using the package-name React Native SDK (CredentialManager) in our Android app to persist authentication data. During a recent security assessment, it was found that authentication data and its encryption material are being stored together in the same SharedPreferences XML file located in the app’s private storage in plain text. Specifically, the file contains a base64-encoded credential blob under the key com.packagename.credentials, expiry timestamps (com.packagename.credentials_expires_at, com.packagename.credentials_access_token_expires_at), a symmetric encryption key (com.packagename.key), the corresponding initialization vector (com.packagename.key_iv), and a refresh capability flag. The concern is that co-locating the encrypted credentials with their decryption key and IV in the same file could allow an attacker with file system access to decrypt and misuse the credentials. Could you please clarify if this behavior is expected in the current React Native SDK implementation? What measures are in place to protect these keys and credentials at rest? Are there recommended configuration changes or SDK updates to improve security here? For example, could these values be stored using Android’s EncryptedSharedPreferences or other Keystore-backed secure storage mechanisms to mitigate this risk? Any guidance on addressing this vulnerability in production apps would be greatly appreciated.
I am sorry about the delayed response to your inquiry!
As far as I have checked regarding the matter, indeed, the React Native SDK’s SharedPreferences appears to raise a security concern in regards to storing both the encryption and decryption keys in the file. This is a default implementation of the SDK. This would not be an issue regarding un-rooted devices, but for those with root access this indeed can impose a security concern since they will have access to the information stored inside the mentioned file.
Regarding the matter, I can propose several solutions and some of them would require to have a custom implementation or a third party library wrapping the SDKs storage:
- Using the React Natives
DataStorageinterface since it is a modern data storage approach which build on Kotlin and overcomes many of the drawbacks ofSharedPreferences. You can read more about that here. - Using the React Native Sensitive Info module in order to handle sensitive data within your application. This is a proposed dependency mentioned in this blog article regarding React Native Authentication. The RNSInfo package will help you automatically encrypt the token using
keystoreand save it into shared preferences. If you want you will be able to add an extra layer of security by requesting user’s fingerprint to unlock the encrypted data. - Use a Secure Storage Library. One of the most common and recommended approaches would be to use a React Native library specifically designed for secure storage on both Android and iOS. I would recommend using one of the following:
react-native-keychain: This is a widely used and well-maintained library that provides a simple API for securely storing credentials. It automatically uses the Android Keystore on Android.expo-secure-store: If you are using Expo, this is the recommended solution. It provides a secure, cross-platform API for storing sensitive data.
- Migrating your Credential Storage would help you to integrate a secure storage library. You will need to override the default
CredentialManagerbehavior since you will not be able to replace theSharedPreferencesfile. You will need to use your chosen library to store the credentials when the SDK returns them, and then retrieve them from the secure store when you need to access them. - You can also change the configuration and the code so that you can set up a custom storage implementation through a wrapper which intercepts the SDKs storage calls and redirect them to your specific secure library.
I hope all of the information above is helpful regarding the matter and if you have any other questions, let me know!
Kind Regards,
Nik