Subject Re: additional firebird security to marry a database to a server
Author Adam
--- In, "Gary Benade" <gary@s...> wrote:
> > Adam wrote,
> >> We are having problems with database theft, and restricting access to
> >> the
> >> server is out of the question. We removed all backup devices on the
> >> servers,
> >> but the database is usually under 1 GIG at client level and USB
> >> memory
> >> sticks are perfect for the job.
> >
> > Why is this out of the question? What a strange comment. If you have
> > the ability to remove all backup devices, then why don't you have the
> > ability to remove all access to one folder on the machine to everyone
> > except the Firebird user?
> > I don't mean to sound unfair, but the security relies on the malicious
> > user not getting file access to the fdb file (just like other
> > databases btw). If you can't guarantee that, then there is little
> > hope. Just in case you were wondering, NO-ONE (except the user
> > Firebird is installed as) requires ANY access at all to the fdb file.
> > So disallow it.
> Hi Adam
> Thanks for your thoughts and comments.
> My problem lies with the fact that not all servers can be secured, and
> controlling access to a server in the wild that is not dedicated and
> actually gets worked on every day is difficult if not impossible.
> Controlling access to folders is fine if you have an OS that
supports it,
> but due to factors out of my control some of the server machines are
> actually running OS's like 98. Shock horror I know, but I have to
> all my clients, even the poor ones.

I understand this problem but unfortunately it doesn't change the
reality. If I can get your fdb file, then I can run it on another
server to bypass your security mechanism.

There is an article in the whitepapers about these issues and more

> Your point on low-level access is well taken and is something I totally
> forgot about. The data isn't really valuable enough for a hacker of
> level to bother with, but I may as well consider it.

Well what sort of user are you hiding it from. I am not talking about
writing a custom server, what about using gbak from another server
where the users passwords can be set?

There are no triggers that Fire on login, and even if there were, they
could easily be altered to skip your check.

> I don't agree with your
> comments on encryption and I think that I might spent some time
> investigating the possibility of encrypting fields containing vital
> using some kind of reversible encryption, like blowfish. Since the
key will
> be store in my application and not the database I think/hope this
will be
> more than sufficient.

How are you sending it to Firebird? Nothing Ethereal can read in plain
text I hope.

If cost is an issue, then Firebird quite happily runs on Linux which
has real file system security, not delete one file and it asks you to
reset the password win98.

Possibly consider something like PGPDisk to create a secure volume for
the FDB file or consider some other delivery method. Our application
is most frequently delivered over terminal services, so our users
never have access to the database files. Heck, they don't even get
access to explorer or about 10 other windows programs where they can
start playing.