> I'm very very new to Firebird, I'm still trying to figure out what
> version I should use. At first I thought the embedded version, was
> just what I needed, since I will only have direct access to the
> database from the same computer as where the database file is located.
> I would then benefit from a small and easy distribution.
> But I would also like just a little security, so that not anybody who
> has access to the database file could read it by logging in as sysdba
> and a dummy password.

The problem isn't only that the user and password are simply trusted
to be valid, but also that the database file is available. Locate
Geoff Worboys' article on security if you haven't already, as it sums
up the attack vectors.

In a nutshell, if you give me access to the database file, I can
simply copy it to another computer where I know the SYSDBA password,
or even open up the file in a hex editor.

Regardless of the server version you use, if you allow them file
system access to the database file, you can not expect any security.
It is just like deadlocking the front door, but leaving the side
window open.

It is possible to somewhat secure a database via NTFS encryption, but
there are a number of additional problems with using embedded. Because
your application is reading and writing to the file (via the embedded
server library), your program must be running with privilleges that
can decrypt the file. Than means resorting to runas or creating a
shortcut to launch with different credentials. It also means XP or
better. If you install Superserver or Classic Server, you can just run
the service as a different user, and give that user the security token
to the database file (as I do on my laptop). It is mostly transparent,
until you want to copy the file to another computer. You need to back
it up to a non-encrypted folder or you can't copy it either, and for
obvious reasons you can't remove the encryption unless logged into
that other user.

By the way, if encryption really worked whilst allowing full access to
the file, you would not have 'data recovery' programs for encrypted
access databases. It is security through obscurity only.

Your best hope is some third party encrypted volume, or to encrypt the
sensitive information before storing it in the database. If you just
want obscurity, rename it from .fdb to .dll or .mdb or something.

Adam