> Shareware authors might like to keep data, and more
> particularly the data model implicit in their table
> and constraint definitions, secure from end user
> 'tweaking', or from analysis by competitors.

> Are there any techniques or suggestions for securing
> FB when deployed on a non-secure server?

The short answer is; No. Once a person has direct access
to the fdb/gdb file there is no security.

The longer answer:

Some people delete the source to their triggers and
procedures because they imagine this hides at least some
of their proprietry database logic - and using this system
you could enforce constraints only in triggers so that the
model cannot be interrogated from the metadata.

But this logic is flawed. It is quite easy to reverse
engineer the BLR. It would be missing the comments from
the source, but SQL is not so complicated that this would
be much of an issue.

Some people have requested that FB provide the ability to
encrypt the database. But even if it did this you cannot
protect the database from authorised users. You could
obscure the decryption key inside the executable, and such
security by obsurity may help protect you from your average
user, but it wont protect you from educated crackers.

Simply put: The engine must be able to read the metadata
in order to maintain database integrity. If its readable
(whatever obscurity you put in place) then you cannot give
anything more than an appearance of security.

There are lots of things that can (and should) be done to
improve FB security, but none will offer any real security
against users with legitimate access to the database file.

--
Geoff Worboys
Telesis Computing