Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Does React Native Keychain use iOS Keychain and Android Keystore under the hood? #641

Closed
msalamacallsign opened this issue Jun 21, 2024 · 9 comments

Comments

@msalamacallsign
Copy link

I am using the React Native Keychain library in my project and I would like to understand more about its implementation. Specifically, I would like to know if this library uses the native iOS Keychain and Android Keystore for storing credentials securely.

@iamaldi
Copy link

iamaldi commented Jun 21, 2024

Hi @msalamacallsign ,

Even though you can, it is not recommended to store username-password credentials in your application's KeyStore/KeyChain.

To your original question, short answer is yes.

On Android, react-native-keychain implements KeychainModule1.
On iOS, it implements RNKeychainManager2

Couple of notes on Android:

Note 1 - there are configurations where you can use react-native-keychain with less secure options3. This could apply to scenarios where you're targeting older devices running older versions of Android for example, where hardware security features might not be available.

Note 2 - use of the "AES" Keychain.STORAGE_TYPE creates a KeyStore key entry that does not require user authentication (e.g., through PIN, passcode or biometrics). As a result, the symmetric key (used to encrypt and decrypt your application's data) can be used without user authentication.

This limitation is also mentioned in the package's README4, however this may not be entirely clear to developers. Existing documentation could use some help to clear this up, which may be a future task for me I guess :).

Footnotes

  1. https://github.com/oblador/react-native-keychain/blob/master/android/src/main/java/com/oblador/keychain/KeychainModule.java

  2. https://github.com/oblador/react-native-keychain/blob/master/RNKeychainManager/RNKeychainManager.m

  3. https://github.com/oblador/react-native-keychain?tab=readme-ov-file#android-notes

  4. https://github.com/oblador/react-native-keychain?tab=readme-ov-file#keychainstorage_type-enum-android-only

@irby
Copy link

irby commented Jul 1, 2024

Hi @iamaldi can you clarify a little more about "it is not recommended to store user credentials in your application's KeyStore"?

For example, on iOS, since react-native-keychain implements RNKeychainManager, is it not storing passwords using Keychain? If this is the case, why is it not recommended to store using your application's key store?

@msalamacallsign
Copy link
Author

@iamaldi Thanks a lot for your answer.

@msalamacallsign
Copy link
Author

Hi @iamaldi

Currently, I am experiencing an issue where the KeyStore/Keychain gets cleared or corrupted on some user devices, and I am unsure why this is happening. I suspect there might be a conflict between a native SDK that we are integrating, which uses the Android KeyStore, and our app's React Native implementation, which uses the react-native-keychain that depends on the OS's KeyStore/Keychain.

I have two clarification questions:

  1. Does react-native-keychain use the bundle/App ID as the key alias in some way?
  2. Does react-native-keychain have a function to clear or reset the Android KeyStore or iOS Keychain?

@iamaldi
Copy link

iamaldi commented Jul 2, 2024

Hi @iamaldi can you clarify a little more about "it is not recommended to store user credentials in your application's KeyStore"?

I have rephrased my original comment to note that I meant username-password credentials.
Unless you have some specific use-case for storing a user's password, depending on your implementation: you can instead store the user's OAuth JWT access/refresh tokens or session identifiers .

For example, on iOS, since react-native-keychain implements RNKeychainManager, is it not storing passwords using Keychain? If this is the case, why is it not recommended to store using your application's key store?

On iOS, application data stored with react-native-keychain's RNKeychainManager, will be stored using Keychain.

Let me know if this clear enough.

@iamaldi
Copy link

iamaldi commented Jul 2, 2024

Hi @iamaldi

Currently, I am experiencing an issue where the KeyStore/Keychain gets cleared or corrupted on some user devices, and I am unsure why this is happening. I suspect there might be a conflict between a native SDK that we are integrating, which uses the Android KeyStore, and our app's React Native implementation, which uses the react-native-keychain that depends on the OS's KeyStore/Keychain.

I have two clarification questions:

1. Does react-native-keychain use the bundle/App ID as the key alias in some way?

2. Does react-native-keychain have a function to clear or reset the Android KeyStore or iOS Keychain?

Can you open a new issue with this topic, and add some more details if possible?

@irby
Copy link

irby commented Jul 2, 2024

@iamaldi Is there a difference between your "application's keychain" versus the device's keychain iOS? If you are using react-native-keychain, which one are you using? My assumption is that react-native-keychain acts as the former, when you use this library it uses the application's keychain to store the value and not the device's keychain.

@MFrat
Copy link

MFrat commented Jul 10, 2024

@iamaldi Could you elaborate why is not recommended to store credentials in keychain and also list some references?

Apple docs says it is completely safe, also in Android. https://developer.apple.com/documentation/security/keychain_services

OWASP also recommends using Keychain for such scenarios: https://mas.owasp.org/MASTG/iOS/0x06d-Testing-Data-Storage/#backups

@DorianMazur
Copy link
Collaborator

DorianMazur commented Nov 12, 2024

Yes, on iOS we use Keychain and on Android we use Jetpack DataStore + Android Keystore. Facebook Conceal is deprecated and will be removed in the next major release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants