At 02:21 PM 5/22/00 +0100, Paul Beach wrote:

>
>> I'm forwarding the following to IB Architects...
>>
>>
>> When you (customer or competitor of my software) just change the isc4.gdb
>> and try to login with SYSDBA to database where we have SYSDBA role
>already,
>> the IBConsole tells you that there is a role named SYSDBA. Now you just
>open
>> the db file with some hex-editor, find word SYSDBA, change one letter e.g.
>> to SYTDBA, save file and connect with SYSDBA, and now you have all
>> information available again.
>>
>> Did I miss something, or is it really this easy? Is there a way to encrypt
>> the whole gdb file?
>>

First, with regards to the authentication mechanism, the whole thing
is under review. Please see the earlier thread on security plugins.

Second, that hack could trash the database. The string "SYSDA" could
occur in many places and there is no way, from a hex editor, to know
which you are tweaking. Futhermore, by zapping the field you are making
the record inconsistent the the index which could lead to all sorts of
unpredicable behaviors.

InterBase used to checksum every page, which would have caught this
hack. It was dropped when it was found to to be a major performance
bottleneck. Do keep in mind that a simple checksum is probably
a hundred times cheaper to computer than a page encryption.

The fundamental basis of InterBase (or any database) security
is that the operating system file security is being used appropriately.
This doesn't work with classic, which one of the reasons that Charlie
and I argue about future support for classic. In SuperServer
there is no need to encrypt the database is the operating system
security is used. For that point, if the operating system security
is not properly used, encryption wouldn't work because the key
would be compromised.

Jim Starkey