> I have an application and is a generic ERP, that I
> want to sell like final copy to the end user (box).
>
> If a user copy the file of the data base for another
> computer, and have access like SYSDBA this user
> obtains all.
> I would like to know how to protect the data base of
> reverse enginner, not allowing that user obtains all
> access to open the data base of external way to
> extract tables, stored procedures and triggers?
> What I can do to protect?
>
> Thanks.
>
> Emerson Muniz
> Brazil

if you are giving them the file then there is very little that can be done.
One thing is to delete all your SP code and leave the BLR. This isn't total
protection but it can slow them down for 5 minutes.
Otherwise there is nothing you can do.
If you don't wnat anyone to have your file, then don't give it to them.
Alan

Here's a reply on this question recetnly from Geoff Worboys.

> peraps any can help me to a method for protect my stored
> proc and table design !!!

Easy. Keep it only on your own computer, isolated from all
networks and in a secure room on an encrypted drive which is
biolocked to your retina scan. Then again even that is no
guarantee. Actually this is semi-serious advice...

If you believe you have some wonderful ways of designing a
database that you really really want to keep secret from the
rest of the world then the only way you would do it using FB
is to host the server yourself and have all your clients
connect to your server. That way you can lock down your db
file and restrict clients such that they never have direct
access to the db file or its metadata.

OTOH if you want to distribute your system then you have to
start making compromises on your security expectations.

(Note: We are talking about security over metadata, not
security over user data. The issue of securing metadata from
legitimate users of the system is quite different to securing
the system from external/unwanted visitors.)


The main aspect at issue here is that FB security is predicated
on the idea that the server should be running on an adequately
secure hardware and operating system ("adequate" is dependent
on the level of security needed) and that the database file is
located in a directory that is not accessible directly from
the network. Thus network users cannot directly see or access
the database file - and so are restricted to making access
through the FB server process.

However if a user has legitimate access to the database file,
as would an administrator of the server (typically one of your
clients), then there is no stopping such a person from copying
the database to another location where the database can be
analysed using a SYSDBA password on that alternative system.
(And even the copy step is not needed if the legitimate client
has the SYSDBA password for the original server - and in all
my installations this is the case.)

So the question is; Can metadata be protected from such
legitimate users of a system?

The simple answer is; No.

Before running off and swearing at FBs inadequacy, first think
about what you are asking - and whether it is really practical.
Then consider some of the commercial alternatives our there
and question whether they really offer any greater security
in this regard, other than possibly some security by obscurity.


Lets just say that FB had encryption on metadata. Who has the
key to decrypt it? If a client running the server has the key
(in order to be able to open the database) then you are left
in the same position as if the stuff was not encrypted. (ie.
You cant use security by obscurity on an open source project,
anyone with the key will have the encryption algorithm and so
be able to extract your full database details.)

I guess you could have the client phone you every time they
want to start their server, then you can dial in and enter the
key for them - but then you are relying on them not installing
some sort of monitoring software to detect what you have
entered.

To get security by obscurity you could compile your own
version of FB with your own encryption algorithms etc. That
would make things a bit more difficult for anyone determined
to discover your secrets - but then they just copy your exes
and well as the database.


I see someone has recommended that you remove metadata source,
distributing only BLR, in an effort to protect your SP and
trigger code. My advice... Dont bother.

BLR is easy to decode, and SP and Trigger code is never so
complicated that the uncommented result would be much of a
problem to decipher. Removing the source code just makes it
more difficult for legitimate maintenance concerns, it does
not stop your metadata escaping.


Consider what happens when you distribute your compiled
executables. There are plenty of decompilers out there. Once
a person discovers what libraries your code was compiled with,
isolating the results to only your own "secret" code makes the
whole process much faster. Have you written to Borland, MS or
whoever requesting that they somehow encrypt their compiled
binaries?


And aside from all that - there is a good chance that it would
not even be necessary to extract your database metadata. Much
about a system can be determined by the way it behaves. There
are very few database applications that I have interacted with
that I could not make some pretty accurate guesses about even
if I never saw the source.


Then there is the philosophical question of why you would
choose an open source database product to build a closed source
database. But thats a whole different argument.


Side Note: If you are interested in having your database
file encrypted there are products like PGPDisk, BestCrypt and
so on that can be used to create an encrypted volume. The db
file could be located on such a volume so that anyone starting
the server without the key cannot access the file. But then
you revert to my question at the top about who has the key and
whether this gives you what you need. It does not protect
metadata but for clients wanting extra security this can
provide excellent added security for their data (provided they
dont mind manually remounting the volume whenever the server
restarts), especially if the server environment not secure
(eg: when office is unattended out of hours).

--
Geoff Worboys
Telesis Computing