> 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.

Even if these inconveniences do showup, they would not deter a determined
attacker to use the simple workaround.

> 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.

Yes, that you have to pay (performance) for encryption is natural. But at
least we should leave it up to the developer to decide whether he wants to
pay the price or not. Now he's no option.

> 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.

I've heard this argument over and over again (especially from Bill K). I
agree that OS security is the way to go, but only ~if~ you have access to
the OS in the firstplace. Unfortunately all those VARs that are embedding IB
into their products, and maybe sell their products shrink wrapped, might not
even know who their customer's are, let alone have access to their OS.

It is in this scenario that IB security leaves a lot to be desired. Is there
anything that can be done?

Cheers

-ST