Wow Alan, that is pretty full on (but good advice)

If we needed to demonstrate our application to a potential customer,
but suspected they may attempt to re-write our front end (although I
expect that would cost them many times more than our license price),
we would simply host the demonstration on our Win2003 Terminal Server.

Create a user for them and add them to terminal server user group.
Configure their environment properties so it automatically loads you
application on login, and ends their session when they quit your
application. Once you have that working, you can lock it down a bit
further. Disallow execution of things like explorer.exe, mmc.exe,
taskmgr.exe, iexplore.exe, and your user will have a hard time doing
anything you your database that you haven't allowed them to do
through your application.

Adam

--- In firebird-support@yahoogroups.com, "Alan McDonald" <alan@m...>
wrote:

> > 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