>If you assume that a) a bad guy has access to the database file and
>b) the bad guy has access to the InterBase source and c) the bad
>guy has the ability to spoof the application to acquire an encryption
>key, then no, I don't think a solution is possible.

Is something like this possible.

Take an example from public key. There are two keys one is public resides
in interbase (or related file) and the other is private and resides in the
application. In order to authentitcase users both the private and public
keys are used to decrypt the user information and passwords (SYSDBA or
not). This way if somebody replaces your file with theirs it does no good.

As for the hiding the schema info. Could it be possible to allow or
disallow schema views based on a user permission? This way the application
can log in using a special user which allows schema views and nobody else
is allowed to see table information. If this is not possible then I suppose
the best bet is to obfuscate the object names so that sql statements look
like select * from alkdfsg where asdfjh=20 which would be a pain to maintain.

Furthermore the connection can be encrypted using openssh if plaintext is
being transmitted.

It seems to me like there are a lot of security mechanisms which are very
well known and documented surely one can be co-opted no??



:wq
Tim Uckun
Due Diligence Inc. http://www.diligence.com/ Americas Background
Investigation Expert.
If your company isn't doing background checks, maybe you haven't considered
the risks of a bad hire.