There is a central database on a server, holding all the authorization data.

The clients each hold a mirror of a part of the central database.

At regular intervals, the client go online to connect to the central server, and update its local database to match that of the central server.

The purpose of the local authentication database is that a program running on the client can determine what levels of access users (when the client is offline) are authorized to when running the program.

Are there any general best practices on how to protect the local database on the client from being viewed and manipulated by unathorized users?

I hear you saying that you are downloading an authentication database to a local client and you want to prevent unauthorized users from viewing the data. Do I have that correct?
–
schroederJan 11 '12 at 17:13

Yes. I want to prevent all users of the client from viewing and manipulating the data. A program on the client is allowed to read the data. The only instance that is allowed to manipulate the data is the central system that updates the authentication database.
–
Lars AndrenJan 12 '12 at 7:17

But I don't think that's true. The source of the updates is the remote database, but it's the local client that performs the update. Or, am I missing something?
–
schroederJan 12 '12 at 15:12

Again, yes, you are of course correct. The new data comes from the central server, but it is the local client that performs the update.
–
Lars AndrenJan 13 '12 at 7:17

2 Answers
2

Are these (local and central) databases holding authorization or authentication data (or both)? Your question refers to it using both ways.

But, whichever it is, if the database is local and the user (or, equivalently, a process running as that user) has to be able to read it (e.g. to check that they have valid authentication/authorization) and that read has to be (by definition!) before the user is authenticated and authorized, then you are out of luck -- the user will need to have read access so they will be able to read the data.

You may be able to prevent modification of the data (or at least detect and reject such modification e.g. via a cryptographic signature/public key encryption using a private key held on the server whose public key pair is held on the client machine) but the user could still subvert the authentication/authorization within the client application's "offline" mode by modifying/injecting into the locally running code.

In addition to any such "roadblocks" you'll also need to make sure that when the client reconnects, the server prevents any unauthorised changes which were made while in offline mode from propagating to the server.

1- This is not a good model if users have strong enough incentive to access the data they are not supposed to have access to (since it looks like they have all the data but the client software prevents them from "seeing" all of it based on the permissions defined in the database)

2- If you must do it the way you say, you need to encrypt the client database.