You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are some security concerns related to our integration / usage of react-native-keychain, especially with regards to Android.
Subtasks
1. Ensure StrongBox is used when supported by the Android device
This should be fixed with a simple upgrade of react-native-keychain to v8.1.3 or higher. See PR:
2. Consider making use of accessibility, access groups for both platforms
Status
Acknowledged but warrants no changes in our view.
Not seeing this as needed for our use case, here's why:
In Bitkit we already enable biometrics as an option, so there won't be any way to access and decrypt the keychain data. Though, presumably someone could get it provided they have the Bitkit specific info for writing the data.
Available Options
If we decide to implement this, below are the settings we can use both for iOS and Android.
1. Access Control
2. Accessibility
3. Consider enforcing highest securityLevel when storing/retrieving encrypted data
This is entirely redundant, the library has an auto mechanism to determine the best possible securityLevel when none is specified from TypeScript, which is how we're using it in keychain.ts.
4. Review the usage of SharedPreferences, which are deemed deprecated, and assess whether this needs to be addressed.
Details
4. SharedPreferences usage in react-native-keychain Android
The library uses plain old SharedPreferences to store encrypted data via the API method that we're using in Bitkit, ie. Keychain.setGenericPassword(…).
While the claims of this posing security concerns feel far-fetched to me, it's nonetheless nowadays recommended to use DataStore instead.
This was merged about a month ago, see #1611. I've been testing Bitkit v1.0.0-beta.113 for the past week, which includes this change. Pin/biometric has been covered quite extensively so I'm satisfied with the regression check coverage.
There are some security concerns related to our integration / usage of
react-native-keychain
, especially with regards to Android.Subtasks
This should be fixed with a simple upgrade of
react-native-keychain
tov8.1.3
or higher. See PR:2. Consider making use of accessibility, access groups for both platforms
Status
Not seeing this as needed for our use case, here's why:
Available Options
If we decide to implement this, below are the settings we can use both for iOS and Android.
1. Access Control
2. Accessibility
securityLevel
when storing/retrieving encrypted datasecurityLevel
when none is specified fromTypeScript
, which is how we're using it inkeychain.ts
.SharedPreferences
, which are deemeddeprecated
, and assess whether this needs to be addressed.Details
4.
SharedPreferences
usage inreact-native-keychain
AndroidThe library uses plain old
SharedPreferences
to store encrypted data via the API method that we're using in Bitkit, ie.Keychain.setGenericPassword(…)
.While the claims of this posing security concerns feel far-fetched to me, it's nonetheless nowadays recommended to use
DataStore
instead.I opened a PR in
react-native-keychain
for this:SharedPreferences
withDataStore
Preferences oblador/react-native-keychain#629The text was updated successfully, but these errors were encountered: