views:

46

answers:

3

Greetings!

I'm needing to deploy a compact database with an application I am working on. The database acts as a cache for data the app has already seen, and that data will never change, so the cached values will never become outdated. I've chosen SQLite, and I'm writing in C#.

I'd like to protect the database files so they cannot be easily accessed or edited by the user - keeping access to my application only. Now, one option is to use password protection which is fine except that with tools like Reflector one could easily view a near original version of the source and check the passwords/how they are generated per file and replicate this.

Are there any suggestions on how to achieve this result or something close? Have people done something like this in the past?

Thanks!

+4  A: 

Security by obscurity.

If your apps can decrypt it, then your user can do it too.

If you want to keep it secure, you'll have to keep it for yourself. Your best bet is to store the database on a server and make it available via a web service. Perform access control checks on your own server so that the application can only access the parts of the database it has to see.

Mehrdad Afshari
+1 - Exactly, if nothing else they can hook it up to a debugger and look in the (unencrypted) memory of the process.
Eric Petroelje
This is what I was fearing. Though I would have thought that something like this would be common enough that a standard solution would exist.. It doesn't make sense to have the database on a server as it's acting as a cache to specific requests from the user, and is there purely as a performance benefit.
filip-fku
@filip-fku: If there were a real solution, DRM guys would have already used it. This is essentially the classic [a-hole](http://en.wikipedia.org/wiki/Analog_hole) problem.
Mehrdad Afshari
@Mehrad - a-hole problem, I like it! Thanks for providing this info.
filip-fku
+1  A: 

I don't have a clearcut answer for you (obfuscate your code during release deployment, make the password obscenely long) as the golden rule stands: If they have physical access to the executable (substitute machine/car/door) they can get in if they want(and have skills).

All you can do is make things difficult for them.

Caladain
A: 

This area is not my forte, but one thing I could suggest is to just think about what data you are actually sending and determine if there is any way that you can limit any of the more sensitive data from being transmitted to the client in the first place.

If your concern is over sending things like ID numbers account numbers to the client, then perhaps you could translate those values into a client-only version that is meaningless outside of your application. Your server could have a table that contains the translation between the real values and the client-only values.

Let's say you have this table stored in your server's database (not the client database!)

RealAccountNumber   ClientOnlyAccountNumber
981723              ABC123
129847              BCD234
923857              CDE345
...

So the client only sees the account numbers in the ClientOnlyAccountNumber column, and when a client sends a request to the server for an action to be performed on account "ABC123", the server knows to translate that into account number 981723.

Dr. Wily's Apprentice
Nice idea for a different question! :) All I'm concerned about is locking out users from accessing local file-databases.
filip-fku