How much is secure?

[oblador]

How much is secure?

[pcoltau]

Pull request created: #67

[MacKentoch]

So I wonder why this library doesn't use android Keystore system to make android store safer.

There must be a good reason considering the nice quality of @oblador libraries.

[vonovak]

@i8wu @pesehr SharedPreferences aren't 100% secure - they are stored in a file and if you root the phone and manage to mount its file system you could read the preferences. For that reason, conceal is used. Conceal itself handles the encryption and decryption of what is stored. edit: on rooted devices, the data won't be 100% secret even with conceal since the key is present locally

[i8wu]

#12 (comment)

[oblador]

This is now released as stable in 2.0.0, thus closing this issue.

[pesehr]

@i8wu SharedPreferences is secure for saving your data but not recommended for saving key pairs.
Android Keystore system is better, in this system private keys are saved and encrypted and apps can't access them directly. It's an essential point for some apps like purchase apps.

[i8wu]

Do you mean to ask how secure the things being stored with this module are? I'm also a bit curious so I looked at the code a bit...
For iOS, it seems to be using the native keychain to store the password
For Android, it's using Facebook's conceal along with Android's SharedPreferences

I can't totally vouch for the security of this module...but it seems to be acceptable.

[pesehr]

@i8wu
SharedPreferences is not secure.
I think it's more secure : https://github.com/pesehr/react-native-secure-KeyStore

[i8wu]

@pesehr Why isn't SharedPreferences secure? An app's SharedPreferences is usually only accessible by the app itself.

[i8wu]

But this module does encrypt the data using https://github.com/facebook/conceal , In what way is Keystore better than SharedPreferences?

Other apps also can't access another's sharedprefs unless specified http://stackoverflow.com/a/6030399/6707153

[dburgmann]

does it enforce the
kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly

Attribute on iOS?

That attribute enforces:

• Your device must be unlocked for the secret to be accessible.
• Your device must have a device passcode set. If you turn off your device passcode, the secret is deleted.
• The secret cannot be restored to a different device.
• The secret is not included in iCloud backups.

---

edit: okay after reviewing the code again it looks like this can be set. Maybe it should be included in the readme.

[pcoltau]

I am also quite concerned with the security of the Android implementation. The SharedPrefsBackedKeyChain used for encrypting the content, stores the 256-bit encryption key in the SharedPreferences on the device. This means that the encryption key and encrypted content is stored in the same place, which effectively makes the encryption pointless.

[vonovak]

@pcoltau that is a fair point... but is there a safe way of storing secrets on rooted devices?

[pcoltau]

@vonovak Well, a rooted device is a worst case scenario, which I don't think you can do much about. However, there have been many exploits, that did not require a rooted device, that would give an attacker access to parts of an app's data.

Using the KeyStore will, on newer devices, ensure that all encryption keys are stored on the hardware, which greatly enhances the protection: https://source.android.com/security/keystore/

I am currently working on a KeyStore implementation of the Android implementation of react-native-keychain - I'll make a pull request when it is ready.

[oblador]

Released an RC with this functionality, would be grateful for anybody testing it thoroughly before we can release as stable. Test it with yarn add [email protected]

[jrnk]

I'm wondering if this 2.0.0-rc is tested (thoroughly) by anyone yet the past two months? I'm investigating the options to use it for securing private key storage on Android devices with API levels < 23.

[chris-yoon90]

I've been using 2.0.0-rc for the past two months on prod with API level 23, and it hasn't had any problems so far. Then again, I only use setGenericPassword and getGenericPassword methods so probably not the "thorough testing" you might be looking for.