0

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).

Community
  • 1
  • 1
Thunderforge
  • 19,637
  • 18
  • 83
  • 130
  • http://stackoverflow.com/a/5877130/1296660 – Supericy Apr 23 '13 at 04:23
  • Where does the program get the password from? Is it shipped together with the databases? – Thilo Apr 23 '13 at 04:23
  • How big are the databases? Can you load them into memory completely? – Thilo Apr 23 '13 at 04:25
  • duplicate of http://stackoverflow.com/questions/9314844/java-password-protect-sqlite-database-using-jdbc?rq=1 (which does not have an answer), also related (but no Java connection): http://stackoverflow.com/questions/2571620/encrypt-decrypt-sqlite-database-and-use-it-on-the-fly?rq=1 – Thilo Apr 23 '13 at 04:26
  • @supericy As far as I can tell, those won't work because I'm using sqlite4java. – Thunderforge Apr 23 '13 at 04:28
  • @Thilo They're fairly small (200 KB max). The program would have the passwords either hardcoded or inputted by the user and the databases would be shipped with the program. – Thunderforge Apr 23 '13 at 04:28
  • If the program includes both the password and the databases, then you have only gained a bit of security through obscurity (an interested hacker can just get the password from the program). May not be worth it. Middleground: give the database an obscure or misleading name (not mydb.sqlite3 but commons-io-3.2.1.jar). – Thilo Apr 23 '13 at 04:30

2 Answers2

3

"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".

Thilo
  • 257,207
  • 101
  • 511
  • 656
  • Not sure what you mean by users don't open APK. The whole point of an authenticated public key is that it prevents people from opening your file. – Thunderforge Apr 23 '13 at 05:06
  • Sorry, I thought we're talking about Android packages (APK). Replace with EXE or JAR or however you ship the program. – Thilo Apr 23 '13 at 05:07
  • Right, I realize that I can't prevent someone from opening up an application binary. I was hoping for something a bit more secure than just renaming the file though. Bundling it into an EXE would satisfy this, but that seems like a pain to manage. – Thunderforge Apr 23 '13 at 05:10
  • 1
    "Pain to manage" is exactly what I am driving at. If this is really important for you, look for another database driver that supports encryption. Don't take time away from your application programming for this. – Thilo Apr 23 '13 at 05:23
  • This is probably the best answer and your last comment about not taking time from programming because of this is well noted. – Thunderforge Apr 23 '13 at 05:55
0

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.

Pradeep Pati
  • 5,779
  • 3
  • 29
  • 43
  • I'm afraid that downloading the database on the fly isn't an option (the user might not have an internet connection), and this would be used on a desktop application, not on a phone (at least for now). Also, I'm more concerned with someone opening up the file once it's on the computer. – Thunderforge Apr 23 '13 at 04:36
  • 1
    also, people can decompile java to see what you have done and how you have done, so don't rely on security through obscurity. – Pradeep Pati Apr 23 '13 at 04:48
  • Wouldn't it take much more effort to decompile my java code and search for the key than it would be to just open up the database file in a sqlite3 command and look at it? – Thunderforge Apr 23 '13 at 04:49
  • I am talking about the scenario where you have it encrypted it. – Pradeep Pati Apr 23 '13 at 04:53
  • What if I encrypted it ahead of time through some other means, then sent the encrypted file with the program? The decryption key would be in there somewhere, but again, you'd have to decompile the program and then hunt for it. – Thunderforge Apr 23 '13 at 04:55
  • difficult bot not impossible. – Pradeep Pati Apr 23 '13 at 04:56
  • What I'm trying to do is make it as difficult as possible. I understand that it won't be 100% effective so long as the program is decrypting things by itself. – Thunderforge Apr 23 '13 at 04:57