search

iamMehedi / Secured-Preference-Store

A cryptography library and a SharedPreferences wrapper for Android that encrypts the content with 256 bit AES encryption. The Encryption key is securely stored in device's KeyStore.
562 stars 97 forks source link

Hiding the names of files #21

Closed Onimishra closed 6 years ago

Onimishra commented 6 years ago

An open-source security library should not advertise its own use to the world. If an attacker gets access to the filesystem, he would be able to see what library that was used, simply based on the names of the files stored (SPSfile and the sps prefix of the keys on old devices).

With this changed to be configurable by the user, and with a good suite of obfuscation and string encryption tools, it is much harder for an attacker to find out which library (if any) was used to make the encrypted preference store.

All log statements has been removed for the same reason.

iamMehedi commented 6 years ago

Making the file name and key prefixes user configurable is a good addition. But I don't think that'll improve the security much. If an attacker has access to the file, he also knows which app has created it and he can easily find out which libraries that particular app is using.

javichaques commented 6 years ago

@iamMehedi Can you accept this pull request and publish a new realease? I need this feature to change the preferences file name.

Thank you

iamMehedi commented 6 years ago

@javichaques there are a few changes pending in this pull request. As soon as those are resolved, I can merge and publish a new version.

Onimishra commented 6 years ago

Sorry about not following up on this pull request. I'll try to amend the commit and submit again.

Onimishra commented 6 years ago

Okay, here we go. I ended up creating old constructors and init methods for both SecuredPeferenceStore and EncryptionManager. Using this, will initialise everything so it can read and write data in the same manner as 0.5.0. This means, people who just update will not break their apps. All logging has been reinstated. It is now done through a logger class, making it possible to turn it on/off from central location. It is on in DEBUG mode, and can be turned on in RELEASE with a method call. Now, to get reliably to 0.6.0. This was a bit more tricky (as all data migration always is). I've created the beginning of a migration tool. The end user can supply Migration instances, going from what was released when their app was first released. For now, that would be 0.5.0 to 0.6.0. Doing it this way, means that each migration level can get supplied with just the parameters that the specific level needs. For 0.6.0, that would be bitshift and filename. We can not change the prefix during upgrade, as we do not now the keys - they are hashes. Instead, I write an "override" prefix to the updated store, so even though the new store is initialised with "myPrefix", if the store was an update, it will still get "sps" loaded. Clean installs will have the "mePrefix". A version number is now also present in the store, keeping track of what level the data set is at. This is nesssesary for future migrations.

As I don't have a big fleet of hands-on devices to test this on, and it's difficult to test on AWS DeviceFarm or Firebase Test Lab due to the need to upgrade an app halfway through, this has only been tested in emulators running different versions of stock Android.