SQLite Context.MODE_PRIVATE - android

I want to know:
Can we use Context.MODE_PRIVATE in SQLite while Database creating to protect from unwanted Database access.
I am not getting any example on google.
How to use this Context.MODE_PRIVATE in Database.
Please assist me. Provide any link or sample.
IN THIS LINK they are talking about file. so Database is also file.
How can i implement this?

As commonsware mentioned, SQLite databases on internal storage are private by default. But as mentioned by others rooted phone as always access to your file.
Rather you can use any encryption algorithm to save the data in DB which will help you to restrict the readability unless intruder know the encryption algorithm.
You cant set "Context.MODE_PRIVATE" flag in SQLite.

While creating database, following syntax is useful
openOrCreateDatabase(String path, int mode, SQLiteDatabase.CursorFactory factory)
For example,
openOrCreateDatabase("StudentDB",Context.MODE_PRIVATE,null);
See my tutorial on this site.

Option 1: Use SQLcipher.
Option 2: Secure Method Ever No Chance To Hack. It is not perfect, but it is better than nothing.
1) Insert data using this Function:
public static String getEncryptedString(String message) {
String cipherText = null;
try {
Cipher cipher = Cipher.getInstance("AES/ECB/PKCS5Padding");
cipher.init(Cipher.ENCRYPT_MODE, new SecretKeySpec(("YOUR-SECURE-PASSWORD-KEY").getBytes(), "AES"));
byte[] bytes = cipher.doFinal(message.getBytes());
cipherText = Base64.encodeToString(bytes, Base64.DEFAULT);
} catch(Exception ex) {
cipherText = "Error in encryption";
Log.e(TAG , ex.getMessage());
ex.printStackTrace();
}
return cipherText;
}
2) Get data from the database and pass into this function parameter:
//This function returns output string
public static String getDecryptedString(String encoded) {
String decryptString = null;
try {
byte[] bytes = Base64.decode(encoded, Base64.DEFAULT);
Cipher cipher = Cipher.getInstance("AES/ECB/PKCS5Padding");
cipher.init(Cipher.DECRYPT_MODE, new SecretKeySpec(("YOUR-SECURE-PASSWORD-KEY").getBytes() , "AES"));
decryptString = new String(cipher.doFinal(bytes), "UTF-8");
} catch(Exception ex) {
decryptString = "Error in decryption";
ex.printStackTrace();
}
return decryptString;
}
3) Benefits of these methods:
- Not possible to decrypt without the right Key.
- AES Encryption is a very secure encryption method.
4) Store your AES key in the c++ file.

Related

How to make our android app more secure, currently I'm using Algorithm for store data in Shared preference, It is okay for user security?

Currently I'm using Algorithm to store data in Shared preference, It is okay for user security?. Below is the code,
private static SecretKey getSecretKey(Context context) throws NoSuchAlgorithmException {
String secretKeyString = PreferenceUtils.getSharedPreferences(context).getString(PreferenceUtils.SECRET_KEY, null);
if (secretKeyString != null) {
byte[] bytes = Base64.decode(secretKeyString, Base64.DEFAULT);
return new SecretKeySpec(bytes, AESEncryption.KEY_GENERATOR_ALGORITHM);
} else {
SecretKey secretKey = newSecretKey();
secretKeyString = Base64.encodeToString(secretKey.getEncoded(), Base64.DEFAULT);
PreferenceUtils.getSharedPreferences(context).edit().putString(PreferenceUtils.SECRET_KEY, secretKeyString).commit();
return secretKey;
}
}
No, its not safe to save sensitive data on shared preferences.Because Java code can be easily decompiled. C++ on the other hand can’t be decompiled but can be disassembled, which is slightly less trivial.So can store the static data like secret key, google api key or any other keys in c/c++ file using Android NDK. From here you can get the reference Android NDK

Android - Use Fingerprint scanner and Cipher to encrypt and decrypt multiple strings

I need an end to encrypt different strings and related decryptions after user authenticate using fingerprint scanner.
Following this project (https://github.com/StylingAndroid/UserIdentity/tree/Part1) and changed "tryEncrypt" method like below:
private boolean tryEncrypt(Cipher cipher) {
try {
cipher.doFinal(SECRET_BYTES);
String one = "augusto";
String two = "test#gmail.com";
String three = "3333333331";
byte[] oneEnc = cipher.doFinal(one.getBytes());
byte[] twoEnc = cipher.doFinal(one.getBytes());
byte[] threeEnc = cipher.doFinal(one.getBytes());
Log.d("test", "oneEnc: " + Base64.encodeToString(oneEnc,0));
Log.d("test", "twoEnc: " + Base64.encodeToString(twoEnc,0));
Log.d("test", "threeEnc: " + Base64.encodeToString(threeEnc,0));
} catch (Exception e) {
e.printStackTrace();
return false;
}
return true;
}
I'm getting this error:
java.lang.IllegalStateException: IV has already been used. Reusing IV in encryption mode violates security best practices.
What is the correct way on how to do it?
Thanks
*******************UPDATE:*****************************
To help others to get solve this problem I used this library and worked like charm:
https://github.com/Mauin/RxFingerprint
You have a problem because your are using a single instance of the Cipher for multiple encryptions (dofinal). You are using a single vector initialization (IV).
Take a look on an option of how to initialize a cipher.
SecureRandom r = new SecureRandom();
byte[] ivBytes = new byte[16];
r.nextBytes(ivBytes);
cipher.init(Cipher.ENCRYPT_MODE, secretKey, new IvParameterSpec(ivBytes));
As you can see, you need to specify the initialization vector. The initialization vector can not be repeated to guarantee that the encryption works.
In your scenario, you probably gonna need to perform a new initialization.
*Ps: It's also possible to use the Cipher initialization without the IvParameterSpec. In this scenario, the class will generate one for you. However, I believe that you need to perform a initialization per DoFinal to guarantee some randomness.
To help others to get solve this problem I used this library that worked like charm:
https://github.com/Mauin/RxFingerprint

Using a custom subclass of SharedPreferences with PreferenceActivity or PreferenceFragment

I'm using a custom subclass of SharedPreferences to encrypt my saved settings in the app, similar to what's being done in the second response here: What is the most appropriate way to store user settings in Android application
The number of preferences I have to save is growing. Before I was just using a custom view to update these preferences but that is going to become cumbersome and I want to use PreferenceActivity or PreferenceFragment instead. Problem is, it does not seem that there is a way to have either of those classes access my data using my subclass, meaning that the data it pulls from the default preferences file is going to be gibberish as it wasn't decrypted.
I've found that some people have created custom implementations of Preference that encrypt the data there, but I'd prefer not to do that as the data is already being encrypted/decrypted in my SharedPreferences subclass and I'd like to keep it that way. I've also been looking over the source code of PreferenceActivity and PreferenceManager and I'm not sure the best way to approach this.
Has anyone else had any luck accomplishing something like this and have any suggestions as to where I might start?
I think by keeping your encryption in the SharedPrefs subclass that you already have, you limit the modularity and the separation of concerns.
So I would suggest reconsidering sub-classing the preference classes themselves (such as CheckBoxPreference) and perform your calculation there.
Ideally you could also use some type of composition or a static utility so that while you might have to subclass each type of preference you use, you can use a single place to perform the encryption/decryption calculations. This would also allow you more flexibility in the future if you need to encrypt or decrypt some other data or if the API changes.
For sub-classing maybe you could do this:
So for example:
class ListPreferenceCrypt extends ListPreference
{
ListPreferenceCrypt (Context context, AttributeSet attrs) {
super ( context, attrs );
}
ListPreferenceCrypt (Context context) {
super ( context );
}
#Override
public void setValue( String value )
{
//encrypt value
String encryptedVal = MyCryptUtil.encrypt(value);
super.setValue ( encryptedVal );
}
#Override
public String getValue( String key )
{
//decrypt value
String decryptedValue = MyCryptUtil.decrypt(super.getValue ( key ));
return decryptedValue;
}
}
NOTE the above is psuedo-code, there would be different methods to override
And your XML might look like this:
<PreferenceScreen
xmlns:android="http://schemas.android.com/apk/res/android">
<PreferenceCategory
android:title="#string/inline_preferences">
<com.example.myprefs.ListPreferenceCrypt
android:key="listcrypt_preference"
android:title="#string/title_listcrypt_preference"
android:summary="#string/summary_listcrypt_preference" />
</PreferenceCategory>
</PreferenceScreen>
EDIT
Caveats/Decompiling
As I thought about this more, I realized one of the caveats is that this method is not particularly difficult to bypass when decompiling an APK. This does give the full class names of overriden classes in the layouts (though that can be avoided by not using XML)
However, I don't think this is significantly less secure than sub-classing SharedPreferences. That too, is susceptible to decompiling. Ultimately, if you want stronger security, you should consider alternative storage methods. Perhaps OAuth or the AccountManager as suggested in your linked post.
How about this:
Store a byte[16] in a .SO. If you do not use a .SO then make one just for that purpose.
Use that byte array to crypt a new byte[16] then Base64 encode the result. Hardcode that in your class file.
Now that you've setup the keys let me explain:
Yes, potentially one could peek into the .SO and find the byte array ergo your key. But with the cyphered key2 being base64 encoded, he would need to decode it and reverse the encryption with the said key to extract key2 bytes. So far this only involves dissassembling the app.
When you want to store encrypted data, first do a AES pass with key1, then a AES/CBC/Padding5 pass with Key2 and an IV*
You can safely Base64 encode the IV and save it like that in your /data/data folder if you'd like to change the IV every time a new password is stored.
With these two steps disassembling the app is no longer the only thing required, as it's now required to also take control of your runtime to get to the crypted data. Which you have to say is pretty sufficient for a stored password.
Then you could simply store that into SharedPreferences :) That way if your SharedPreferences get compromised, the data is still locked away. I don't think subclassing it is really the right approach but since you already wrote your class - oh well.
Here's some code to further illustrate what I mean
//use to encrypt key
public static byte[] encryptA(byte[] value) throws GeneralSecurityException, IOException
{
SecretKeySpec sks = getSecretKeySpec(true);
System.err.println("encrypt():\t" + sks.toString());
Cipher cipher = Cipher.getInstance("AES");
cipher.init(Cipher.ENCRYPT_MODE, sks, cipher.getParameters());
byte[] encrypted = cipher.doFinal(value);
return encrypted;
}
//use to encrypt data
public static byte[] encrypt2(byte[] value) throws GeneralSecurityException, IOException
{
SecretKeySpec key1 = getSecretKeySpec(true);
System.err.println("encrypt():\t" + key1.toString());
Cipher cipher = Cipher.getInstance("AES");
cipher.init(Cipher.ENCRYPT_MODE, key1, cipher.getParameters());
byte[] encrypted = cipher.doFinal(value);
SecretKeySpec key2 = getSecretKeySpec(false);
System.err.println("encrypt():\t" + key2.toString());
cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
cipher.init(Cipher.ENCRYPT_MODE, key2, new IvParameterSpec(getIV()));
byte[] encrypted2 = cipher.doFinal(encrypted);
return encrypted2;//Base64Coder.encode(encrypted2);
}
//use to decrypt data
public static byte[] decrypt2(byte[] message, boolean A) throws GeneralSecurityException, IOException
{
SecretKeySpec key1 = getSecretKeySpec(false);
System.err.println("decrypt():\t" + key1.toString());
Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
cipher.init(Cipher.DECRYPT_MODE, key1, new IvParameterSpec(getIV()));
byte[] decrypted = cipher.doFinal(message);
SecretKeySpec key2 = getSecretKeySpec(true);
System.err.println("decrypt():\t" + key2.toString());
cipher = Cipher.getInstance("AES");
cipher.init(Cipher.DECRYPT_MODE, key2);
byte[] decrypted2 = cipher.doFinal(decrypted);
return decrypted2;
}
//use to decrypt key
public static byte[] decryptKey(String message, byte[] key) throws GeneralSecurityException
{
SecretKeySpec sks = new SecretKeySpec(key, ALGORITHM);
System.err.println("decryptKey()");
Cipher cipher = Cipher.getInstance("AES");
cipher.init(Cipher.DECRYPT_MODE, sks);
byte[] decrypted = cipher.doFinal(Base64Coder.decode(message));
return decrypted;
}
//method for fetching keys
private static SecretKeySpec getSecretKeySpec(boolean fromSO) throws NoSuchAlgorithmException, IOException, GeneralSecurityException
{
return new SecretKeySpec(fromSO ? getKeyBytesFromSO() : getKeyBytesFromAssets(), "AES");
}
What do you think?
I realize it might be off topic since you're asking about using your own SharedPreferences but I'm giving you a working solution to the problem of storing sensitive data :)

How to Encrypt Session Values in Android

I'm developing an Android app which based on a web-server. Users, who installed the app, should register on web, so they can login. When someone try to login I verify their information with API.
So I'm curious about persisting and encryption processes. Should I encrypt the values or just put them all to SharedPreferences? If encryption is needed what's the efficient way?
And last but not least, Is SharedPreferences enough in terms of security?
Thanks.
Encryption is easy, but the real question is with what key? If you hardcode the key in the app, or derive it from some known value, anyone with access to the device can easily decrypt those values. What you are achieving is merely obfuscation. Since Android doesn't have a public API to the system keystore, there is not much else you can do if you need to save the actual password. Unless of course you make the user input a password each time they start the app, which kind of defeats the purpose.
If you control both the server and the client, another approach is to use some form of token-based authentication and only save the token. Since tokens can expire and be revoked, the damage by someone getting hold of your token is much less, than exposing an actual password (which may be used on other sites as well).
Of course you should encrypt user settings like login, password or maybe email. I prefer SharedPreferences for storing, and yes it's enough in terms of security.
I've found this two method on StackOverflow, it's fair enough:
protected String encrypt( String value ) {
try {
final byte[] bytes = value!=null ? value.getBytes(UTF8) : new byte[0];
SecretKeyFactory keyFactory = SecretKeyFactory.getInstance("PBEWithMD5AndDES");
SecretKey key = keyFactory.generateSecret(new PBEKeySpec(SEKRIT));
Cipher pbeCipher = Cipher.getInstance("PBEWithMD5AndDES");
pbeCipher.init(Cipher.ENCRYPT_MODE, key, new PBEParameterSpec(Settings.Secure.getString(context.getContentResolver(),Settings.System.ANDROID_ID).getBytes(UTF8), 20));
return new String(Base64.encode(pbeCipher.doFinal(bytes), Base64.NO_WRAP),UTF8);
} catch( Exception e ) {
throw new RuntimeException(e);
}
}
protected String decrypt(String value){
try {
final byte[] bytes = value!=null ? Base64.decode(value,Base64.DEFAULT) : new byte[0];
SecretKeyFactory keyFactory = SecretKeyFactory.getInstance("PBEWithMD5AndDES");
SecretKey key = keyFactory.generateSecret(new PBEKeySpec(SEKRIT));
Cipher pbeCipher = Cipher.getInstance("PBEWithMD5AndDES");
pbeCipher.init(Cipher.DECRYPT_MODE, key, new PBEParameterSpec(Settings.Secure.getString(context.getContentResolver(),Settings.System.ANDROID_ID).getBytes(UTF8), 20));
return new String(pbeCipher.doFinal(bytes),UTF8);
} catch( Exception e) {
throw new RuntimeException(e);
}
}
Couldn't find link, if I found, I'll edit my answer.
Edit: I found the source, you may have a look at all discussion on here.

sqlite encryption for android

i'm looking very hard for a possibility to encrypt my sqlite database on Android devices, but I was't able to find a satisfying solution.
I need something like a libary to reference, in order to have a "on the fly" encryption/decryption of my database, while using the normal sqlite functions.
I don't want to encrypt data before storing.
I don't want to encrypt the whole databasefile, in order to decrypt it before using.
I know about the following projects:
SEE
wxSQLite
SQLCipher
SQLiteCrypt
Botan
But I can't find any working example for this stuff.
Btw, I'm absolutly willing to purchase a commercial build, but I have to test ist before spending a few hundred dollars.
Did anyone solve this issue for his own?
Try the SQLCipher port to Android instead of the regular SQLCipher.
litereplica supports encryption using the ChaCha cipher, faster than AES on portable devices.
There are bindings for Android.
To create and open an encrypted database we use an URI like this:
"file:/path/to/file.db?cipher=...&key=..."
If anyone is still looking:
Override SQLiteOpenHelper function as below:
void onConfigure(SQLiteDatabase db){
db.execSQL("PRAGMA key = 'secretkey'");
}
private String encrypt(String password) {
try {
SecretKeySpec keySpec = generateKey(password);
Cipher c = Cipher.getInstance("AES");
c.init(Cipher.ENCRYPT_MODE,keySpec);
byte[] encVal = c.doFinal(password.getBytes());
String encryptedValue = Base64.encodeToString(encVal,Base64.DEFAULT);
return encryptedValue;
} catch (Exception e) {
e.printStackTrace();
return null;
}
}
private SecretKeySpec generateKey(String password) throws Exception {
final MessageDigest digest = MessageDigest.getInstance("SHA-256");
byte[] bytes = password.getBytes(StandardCharsets.UTF_8);
digest.update(bytes,0,bytes.length);
byte[] key = digest.digest();
SecretKeySpec secretKeySpec = new SecretKeySpec(key,"AES");
return secretKeySpec;
}
I just used the encrypt function to encrypt the password. Here I used the user's password as a key. Therefore I don't need to keep the key inside the application. When the user wants to log in, simply encrypt the password and try to match with the encrypted password in the database and allow them to log in.

Categories

Resources