Open HLCaptain opened 8 months ago
You can already use EncryptedSharedPreferences
with the existing SharedPreferencesSettings
.
That is true, but I think there should be more default(er) implementations of secure storage methods, which relies on Android Keystore or other platform specific keystore methods. On JVM, I had to find a way to acquire and save the master key, which is not intuitive to do. On web, this secure storage is even harder to implement. I would like security to be an option in common code, with platform specific secure implementation of settings.
Regarding JVM and JS, I'm open to adding something but not clear on what the best backing API is. If you have any demo code of what worked for you, I'd be interested to see it.
For Android, a couple questions. Is there anything you'd like to do with the Keystore that you can't do via EncryptedSharedPreferences
? And do you have an example of what you'd like to be able to do with the Credential Manager?
Regarding Android platform, yes, I think using EncryptedSharedPreferences
with Android KeyStore
is enough, thanks for pointing that out.
I have an experimental demo working on the JVM side via Credential Secure Storage. It relies on MacOS, Windows and Linux native KeyStore libraries. I still have some bugs to squish, but it works fine on Ubuntu 23 and Windows 11. You can check out platform implementations from here for Common, JVM, Android. I still have to figure out Web. There may be better alternatives to Microsoft's Credential Secure Storage, like CoreCrypto.
As I stabilized my EncryptedPreferences
for JVM, I may make a proper pull request to include it as a solution for making settings encrypted in some sorts.
Currently:
EncryptedPreferences
acts like java.util.prefs.Preferences
, but with encrypted keys and values.I could make the encryption happen in the Credential Secure Storage instead of java Preferences, just like Apple's KeyStore implementation, but I think java Preferences is secure enough for now.
Regarding #211 getting merged into this issue -
One of things I find helpful is differentiating Settings vs. SecureSettings in my apps. Having these two containers make is less likely that I accidentally inject the wrong container.
I typically do this with two marker interfaces:
/**
* Marker interface to differentiate [com.russhwolf.settings.Settings] backed
* by the insecure NSUserDefaults / SharedPreferences vs. the secure
* Keychain / EncryptedSharedPreferences.
*/
interface SecureSettingsContainer : Settings
interface SettingsContainer : Settings
And then create project-specific settings, something like:
class SecureSettings(
secureSettingsContainer: SecureSettingsContainer,
) {
var accessToken: String? by secureSettingsContainer.nullableString()
}
class Settings(
private val settingsContainer: SettingsContainer,
) {
var hasUserOnboarded: Boolean by settingsContainer.boolean(defaultValue = false)
}
This distinction makes it harder on the developer to accidentally make a mistake.
In my DI framework object graph, then, I'll do something like:
single {
Settings(
settingsContainer = /* create settings container for platform, backed by NSUserDefaults / SharedPreferences */,
)
}
single {
SecureSettings(
secureSettingsContainer = /* create secure settings container for platform, backed by KeychainSettings / EncryptedSharedPreferences */,
)
}
My code is generic enough that I wrapped it up in a little library that I use whenever I use muiltiplatform-settings. Happy to submit a PR to add it officially if it's something others would find useful.
As iOS platform supports Keychain experimentally, other platforms have similar secure implementations of a simple key-value storage directly, like Android's Keystore or Credential Manager. Or encrypt your data with a master key, like in EncryptedSharedPreferences, also on Android.
I suggest that the library should provide these secure methods of data persistence. I also vouch for an implementation which relies on master keys, as we may reuse code and only need to encrypt the stored key-value pairs and not rely on an entirely different system.