-
Notifications
You must be signed in to change notification settings - Fork 18
Description
Description
Since you are building a complete set in this library, I thought to also request react-native support, but done in a better way.
Motivation
A better option in the react-native ecosystem. As it lacks a complete and maintained secure option.
Proposed Solution
It could be encrypted in runtime while also served at runtime (as one of the options), but it would require other protections in place most likely. I supose the more options you support given what you already do, the better, as long as you clearly state the security tradeoffs.
It should support, js, native and common used files from native setup that is used by packages sometimes.
Alternatives
Currently there is
- https://github.com/goatandsheep/react-native-dotenv
- https://github.com/react-native-config/react-native-config
But the first two are not very secure. It's not like it's possible to be. Although there is a alternative that does it better. But they do not maintain it very well.
https://github.com/numandev1/react-native-keys
Ideally, yours would be a better version than react-native-keys, from the get-go.
Additional Information
You could use Swift and Kotlin for the native part. Ideally support both old and new arch.
I would suggest to cover other parts that can contribute to being easy to reverse-engineer and get the env vars, that's why it should be a better option than react-native-keys. There are other factors that can still facilitate, perhaps if other security measures were added / in place. Against rooted, emulators, have rasp protections, etc... Perhaps even integrity checks, it could help, once the main parts were addressed. It should be own impl or libraries recommendations.
Currently I have a gist, that could help make sense of this in some parts. https://gist.github.com/dougg0k/60e02f2fd99df129a7e329c92309fd5e
In all points of it, performance are important, but security even more, as stated, if possible have further things done, perhaps even checks within the library using other security related libraries.
Another thing could be, to scramble env vars if compromised. Perhaps have optional integrations with other libraries for more security, including tradeoffs, if any.
Research and understand all the points that can cause env vars to be compromised. Perhaps more counter-measures would be found in the process, to counter any sort of reverse engineering or at least make even more difficult.
https://oss.callstack.com/react-native-builder-bob/create
Not sure how viable it is, but I suppose C++ or Rust could be used for a single implementation and then spread to native and js.