This question already has answers here:
SQLite with encryption/password protection
(9 answers)
Closed 9 years ago.
My desktop Java app uses several read-only SQLite databases, which I would prefer people not be able to open up and look at. Normally, this might be accomplished through encryption, but I'm currently using the sqlite4java library, which does not support encryption and doesn't easily allow other SQLite encryption libraries (e.g. SEE) to be used.
What I'm trying to do is make it as difficult as possible for a "casual hacker" to just find one of these database files and open them up. For instance, someone threw out the idea of sticking them in a password-protected ZIP file, then using a library like the ones suggested here to decrypt it on the fly as either an InputStream or a temporary file.
Would this be something that is worth doing?
EDIT: I realize that this isn't going to be perfectly secure, and a hacker dedicated enough might be able to still find a key and decrypt it (this seems like a vulnerability with any such programs).
"What I'm trying to do is make it as difficult as possible."
You are probably just making it as difficult as possible for yourself.
Regular users don't open application binaries. People that open application binaries have tools to find your encryption key.
If you want to engage in security through obscurity, just name the database file "commons-io-3.2.1.jar" instead of "mydb.sqlite3". No trouble for you, still throws off the "casual hacker".
Instead of password protecting your SQLite DB, you can choose not to ship it with the application APK, rather download the content on first run, so that you don't have to encrypt and decrypt and your APK is lighter.
Also remember, your DB can still be hacked by intense hacker.
Related
I have looked at this answer provided here, and here, and here
The answers provide some useful information but I wanted to know if there are better ways to do it.
I have built my apk and I used pro guard, but when i decompiled the apk, everything was the same as they were before the compression.
The name of the classes and some variables were obfuscated but a Newbie could have looked at the code and would understand how the app works.
In my app I want to hide the core network communication between the app and the server. For example, the address of the server, the JSON format etc.
I came across something as way to protect from decompilation is putting the java.class files into jars and then signing them and then add them as a library to my app.
My question is:
Is it the correct way to do it ie. using the jar signing ?
No. Jar signing is used to make sure the file isn't tampered with. You can still decompile it.
Rather than wasting time worrying about decompilation, you should concentrate on something useful. Obfuscation is used to save space in Android, not to prevent people from looking at your code. Besides, did you really create something so special that you need to protect it? (Be honest now)
I recently found that the databases of Android apps are totally exposed. That said, my configuration is exposed, I save there passwords.
So, now my doubt resumes on java code.
String value = "example";
This could be an example where I store a password to pass by reference to webservice.
People, with some kind of software (like this example Is there a way to get the source code from an APK file?) could be able to get all the code? (I tried to follow the steps without success)
I read about http://developer.android.com/tools/help/proguard.html, how do I know that it's already implemented in my project?
When you create an Android project, a proguard.cfg file is
automatically generated in the root directory of the project.
I checked my root directory and I don't have that file.
Thank you guys.
Obfuscation does not guarantee that your code won't be de-compiled. people who get your apk will still be able to review the code (although the flow of the app will be significantly more difficult to understand). Function names, variables and class names are changed but the code is still viewable.
password and other sensitive information should be kept in Android's keychain , where it's protected. never save passwords in a configuration file (preferences file).
You can look into encrypting your local database with sqlcipher. Proguard obfuscates code but will not hide your passwords if you have them hardcoded anywhere, it is not a tool to be used for security[reference]. Also all of your network traffic is vulnerable unless you use some sort of TLS.
As you describe your app now it is trivial to get the passwords in your app.
You can use char[ ] instead of string data type for storing sensitive values like password. This will make it difficult to recover if someone takes memory dump as value is not present string literal pool if used char[] data type.
This question already exists:
Closed 11 years ago.
Possible Duplicate:
version to folder using java programming
In my Java web application project,I need to add versioning to one of my Images folder,if user done any modification to image and updated then it should maintain new version on recently updated image(similar as svn), to do this i decided to integrate svnkit in my project please tell me how to do this programming or implementation.
This is similar to a question posted earlier... Anyway, SVN is not a very good choice in my humble opinion as it is suppose to be used with text-based files. Why do you want to call a 'diff' on binary files? ...and why? I would recommend one of the following:
Store the images as blobs in a database, that included an MD5 sum of the file, date modified, etc.
If you don't like blobs, store the images in a folder with a time extension (i.e myimage.jpg.20111112_092311_1) and store the md5 sum of the image somewhere else so that you know it got modified.
I have worked with SVN in java apps before. I do not find SVN particularly trustworthy. I would recommend you think carefully before going that route. Your own implementation may actually be better here.
(For md5 sums, search for MessageDigest)
I was wondering what's the security of Android's resources folders (I'm especially concerned with strings). I know, I know, it would be ridiculous to store a password in Strings.xml. It's not like that, but how easy it is to snoop on these resources, to access sensible app info?
Unfortunately it is pretty easy to get to the resources. Tools like apktool enable to do that. I have raised a similar question here. You may want to take a look.
Easy on a rooted phone. Expect anyone can read your string resources shared preferences, etc. I just hooked up ADB, changed to /data/data/com.tumblr/shared_preferences and read my username and password in the clear.
You can also download and decompile the apk. If you need to keep it secret, encrypt it.
The primary rule of thumb here is that ANYTHING stored on the device is open for sniffing and cracking.
There is no such thing as local security against those in physical control of the device.
Even if you encrypt it, the keys for decryption have to exist on the device or be easily accessible by the device.
As a side note, this is the number one reason for features such as Remote Wipe.
So, if you plan on storing something sensitive or just plain don't want a slightly interested user to see the data you've stored on the phone, then you're out of luck.
I know that the xml files are scrambled in the apk, but there is a hacker tool for unscrambling them back to plain text. I can't remember the name of it but I found it OK via Google. It works unfortunately!
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
SQLite with encryption/password protection
My problem is that I am on a struts2 web application and I am creating a sqlite database file dynamically. I need to protect that file (when users download that sqlite file it needs a password to open it, like a password-protected PDF). Is there any other way to complete this task?
There is an encryption library (sqlite-crypt) available in C, but if you want to do it in Java, I would simply encrypt the file like any other file and supply a decryption tool with password for the user. See this example of file encryption/decryption in Java.
The best solution is to install SqlCipher or something similar, but that means that you must build and install a C extension to your Java environment.
If you decrypt the SQLite database on starting your app and then encrypt it on ending then it's "exposed" while you're actually using it (and if the app is terminated abnormally). With SqlCipher the data is always encrypted, even in the middle of an operation. The other alternative is to encrypt/decrypt individual "blobs" stored in the DB, but then you can't search on them, etc.
You can use Zip4j (http://www.lingala.net/zip4j/) to create a password protected zip file.