> it is a balance of cost/benefit

Indeed it is. The trick is to make it cost enough to deter
the unscrupulous. The problem is that with computers the cost
is often such that it is often only incurred once, having
solved the problem once it can be re-used again and again.

If an open source project attempts to provide some form of
data obfuscation then a work-around will very quickly be
found (because it is after all open source so everyone can
see how it is done) and once found it will be available for
all that come along later... costing them almost nothing.


So, instead, you decide to take the source code and create
your own obfuscation (probably by intercepting page read and
write routines). There is no point me or anyone else on this
list telling you how to do this, because then it would be
public information and no longer obscure.

Great, but unless you obscure your metadata and your security
data very carefully (perhaps you obscure the API too) this
can be simply bypassed by taking the binaries at the same
time that they take the database. Then, using a separate
application, they can quickly and easily extract it all to
their own database.... almost no additional cost over an
unprotected database.


So you do also obscure the API and perhaps write your database
to try and prevent other applications interrogating it through
your binaries. I will just do a compare of your binaries
against the original. The differences will be minor and from
those I expect to be able to do one or all of:

. patch into your read routines so that every read (and
so decrypt) that your binaries perform they also write
an unencrypted copy to a separate file.

. patch into the standard security routines to output the
relevant passwords

. patch into the standard security routines so that
every user appears to be a SYSDBA and can do anything

. perhaps pull out your read/write routines and patch them
into my own binaries - so I can now access the data
directly in any way I like.

The above are just ideas off the top of my head. A quick
study of the source code is likely to reveal many places
where I can easily create patches to circumvent your
obfuscation.


Notice that so far I have not had to try and discover the
actual details of your obfuscation, not even what type of
encryption and what key you are using. I just make them
irrelevant. This is easy (does not cost much) because you
are basing your server on code for which I already have the
source and alternative binaries.


So to really make it obscure you would have to write your
own database server and client and never distribute the
source. Now a person wanting to steal your data may finally
have to do some serious work (cost). Not that you will have
stopped anyone that was prepared to put in the work, but if
your data is not that valuable you may have finally done
enough.

If you really think that obscuring your data this way is
going to be worth your while then I suggest you look for a
closed-source database solution. There are several products
out there that pretend to offer security but allowing you to
put passwords on the file. Most of these are kidding
themselves (and their users) about the security, but at least
you will get some obscurity without having to write the whole
lot yourself.

You will not get obscurity from an open-source solution.


Here is a link that covers the FB security issue in more detail:
http://www.firebirdsql.org/index.php?op=doc&sub=whitepapers&id=fb_meta_security

--
Geoff Worboys
Telesis Computing