--- In firebird-support@yahoogroups.com, "mspencewasunavailable"
<firebird@...> wrote:

>
> Our application is being converted from a stand-alone, desktop
> database to Firebird. Our users (mostly small businesses) will be
> running the application and FB together on their Windows system; in
> some cases, even on their laptop.
>
> We'd like to arrange things so that they can't easily see or modify
> our database directly, including the metadata. We understand that
> since they'll have physical access to database, that with enough
> knowledge they can pretty much do anything they want, but we'd like
> to keep the casual user, or competitor, from poking around in
> things, connecting our data to other applications without our
> approval or running reports directly out of the database.
>
> I've changed the SYSDBA password to something obscure in the copy of
> FB that we're going to distribute (so they'd have to download a
> fresh copy to replace the security database).
>
> Currently, our application is using SYSDBA as the username to
> connect. Since our app. will be the only user, ever, is there
> anything to be gained by adding another user and using *that* to do
> the connection?
>
> Is there anything else we can do in this regard besides changing the
> SYSDBA password, like add a table to the security DB so that if they
> replace it, we'll know? There are some things like this in the
> Firebird book, but they were more about keeping legitimate users out
> of trouble in a multi-user situation than keeping anyone from ever
> adding another user or getting at the database in any way beside
> through our app.

Once the data file is physically on a compromised machine, there is
nothing you can do to prevent access. At best you may be able to make
it marginally more difficult.

From Firebird 2 onwards, you will have no direct access to the
security database, so even if you did put a special table in there,
you would no longer be able to access it. Even if you got around that
issue, it is not like you could not just copy the hash from the
standard security database to the official security database with your
magic table.

If you really want to secure things, then you need to get the database
onto a secure host machine.

Adam