> So !!! What may I understand !!!??? there is a mechanism to protect database but it is desabled by an #ifdef??
> Could you illustrate that please by an exemple

The encryption key _could_ be passed in the DPB the same way the user
name, password, encoding are passed. But I think nobody tried the code
so far - it was implemented long time ago by Borland but never released
in public.

Anyway, as it was said here, the issue is the key management. I will
explain you based on Access (I used it few times, but my story might not
be very precise)

In Access, when you protect the database by password, you won't be able
to connect to the database without specifying the right user name and
password. They are stored in the database itself, but in encrypted form.
The encryption key is stored in some other file which is located on your
computer C:\Document and Settings\<your login>\Application
Data\Microsoft\Access\System.mdw (that is also Access database, but some
parts are not accessible when you open it).

When you copy the password protected database to some other place
without copying the .mdw file, you won't be able to connect to it, since
Access won't be able to decrypt the user name and password. To avoid
this you have to copy the .mdw file to the new location (but not replace
the System.mdw, since other databases on that location will be
inaccessible) and specify the file name in connection string (or as a
startup parameter for Access).

In Firebird, when you have server installation and your databases are
protected from direct file access, you're safe - Firebird won't let
anybody with wrong credentials in.

The problems are with embedded engine - the embedded engine does not
require password database, so anybody can open it. The encryption part
that is currently disable does not help you a lot, since anybody can
build his own version of Firebird (remember, we're open source) and dump
the encryption key that application passes to the library to the screen
or log. Having that one, it is easy to create another application that
would dump the data from your database.

Others (incl. the CodeGear with its new release of InterBase) have it
easier - the efforts needed to modify the binary library are
significantly higher, so the most users will be safe.

So, as it was already said, the issue is the key management. In our case
it is harder than in Access or InterBase, since people can replace the
fbembed.dll and dump any key that is used to decrypt the database.

We (developers) have already discussed this issue long time ago, but did
not find any acceptable solution that can be implemented within the next
releases.

It is however thinkable that some third-party company would create a set
of components for Delphi, Visual Studio, etc. that would

a) provide access to embedded Firebird;

b) would check the authenticity of the fbembed.dll
and prevent the application from passing the
encryption key in case of different library.

Roman