Subject Re: [IB-Architect] Re: Nailing down the external file problem.
Author reed mideke
> > >So the question becomes: Do you really want to spend time
> > >on a half-baked security solution?
> >
> > There is no reason, ever, to build a half-baked security system.
> > It must be done right.
> I agree, but the system you have described only covers the way to
> manage passwords. It is definitely worth improving the password
> management if it is as weak as you describe. However it does not
> cover the scenario to which I was responding.
> The earlier posting was looking for a way to "hide" the database
> structure details from the customer. In the past, others have
> complained that a person with access to the server (having the server
> admin password) can copy the database and install on a different
> system where they know the SYSDBA password.
> Can you think of a system that works in this situation?
NO! It is demonstrably impossible. The customer has complete
control of his/her machine. You are saying that software on their
machine (the server) should be able to do something (in this case,
know the metadata structure of 'your' database) that they are not
allowed to do. But by >definition< they can do anything their
machine can do.
It's the old copy protection problem all over again. You can make
it harder, but unlike an encryption problem (where you can say a brute
force attack it will take N guesses on average to get the right
key), you cannot make it >quantifiably< harder. Throwing encryption
at it >does not help< because the key must also be on their machine,
and again, they can read anything on their machine.

Hardware dongles, CD keys, DVD CSS, are all examples of this.
Not only don't they work, they CANNOT work. All it takes is a bored
kid with a disassembler. If you don't believe me, search google
for 'crackz' or 'warez'

The only true solution to this problem would be to not store the
your proprietary data on their machine, and provide them with
interfaces which expose only the data you want them to see.

Given this, I do not believe it is proper for firebird to implement
any kind of metadata copy protection. Since this sort of thing
depends on obscurity, rather than the action of a particular
algorithm, having the source available makes it easier to defeat.

If you >REALY< want to do this, your best bet is to make
your own version of the server, which you do not release the
source to, and implement your copy protection in that.

This WILL NOT make your proprietary data safe, but it will mean
that the bored kid with a disassembler will have to want to
target your specific product, rather than firebird databases
in general.

> Geoff Worboys
> Telesis Computing
> To unsubscribe from this group, send an email to:

Reed Mideke
email: rfm(at) -If that fails: rfm(at)