Hi Lauchlan,

>
> I'm not sure I agree with this analysis . . . it depends what level of
> security you are pursuing. Firstly, if you want the highest level of
> security, you could use SSL and send the client certificate by courier.

Firstly I would like to say it is important to read Geoff's whitepaper
in the context that it is written, protecting the meta-data although
there is certainly some overlap with what you are wanting to achieve.

Firebird security is dealt with on the server level (FB1.5). For the
future direction of how this will be improved, read the FB2 alpha
release notes and there is also a bunch of articles about future
directions, but this comment is assuming Firebird 1.5.

So what are the main weaknesses in FB 1.5 (from a security design
perspective).

1) Anyone who can gain access to either the FDB file or a backed up
file (FBK) can then transfer that file to another machine where the
SYSDBA password is known. They can then read any information they like
out of that database.

2) Users can starve the system of resources by deliberately running
nasty queries or leave lots of transactions open.

I do not understand precisely what you think about as the client, but
I am guessing you are thinking about the customer (rather than client
as in client-server).

In a client-server environment, it is possible to achieve acceptable
security by doing the following:

1) Create the database in a folder that is accessible ONLY the user
the FB service is running under. Do not include this folder in any
sort of share.

2) Using the aliases.conf file, set up the clients so they all point
to an alias, rather than using the path/to/file syntax, as obscurity
goes a long way towards making it more secure.

3) Put the server on the other side of a firewall, and only open port
3050 to a selected IP range. OK maybe that is going a bit overkill,
but my point is that a Firebird client does not need any file access
permission on the server.

Unless I am misunderstanding your concern (which is entirely
possible), you seem to be mixing up data send receive / host
identification security (SSL can be used here) with securing a
database file.

There is a third party product called Zebedee which can be configured
with minimal fuss to connect to Firebird over an insecure channel.
Although I have never been in the position to need this tool because
most of the implementations I have dealt with have either been
client-server or terminal server based installs.

But I think it would be a mistake to assume that simply adding a layer
to encrypt / decrypt the information as it goes to disk is going to
secure a database (in particular an open source database where the
encryption / decryption method is understood, and it is simply a task
of reverse engineering a key).

Personally I did find the article did come across that it was
impossible to truly secure so therefore why should we bother doing
anything, however with security, there is no point putting a time
delay dead bolt and vacuum lock on a safe if the side wall is made out
of paper. There is no point in encrypting a database if you are going
to give the private key to the people you are trying to protect the
database against. So in that sense, I find the article well written,
exposing some security myths and forcing people to actually think
about securing the whole system, rather than simply giving a warm and
fuzzy feeling that everything will be OK when it may not be.


Adam