Subject | Re: [IBO] Security holes? |
---|---|
Author | Geoff Worboys |
Post date | 2013-12-23T08:26:56Z |
I thought that some clarification of the response from ma_golyo
may be appropriate.
Firstly: Lane, it is not clear what you mean by "may have been
compromised" - whether you are speaking of someone having
obtained a copy of the data, or whether someone has been able
to apply unauthorised updates. The former can be achieved via
mechanisms outside the Firebird (or your application) control,
the latter is typically a Firebird or application issue. You
need to specify what you think may have happened to get
anything very useful in the way of responses.
Firebird itself is (at least reasonably) secure within certain
constraints.
One of the common complaints is that, as indicated by ma_golyo,
if a person can gain direct access to the database file then
they can open it on their own system using known a known
password (or version of Firebird that doesn't need one).
However, to gain direct access to the file suggests either
access to the file via the network, or direct access to the
server on which Firebird resides. Either of which are contrary
to a secure design and out of Firebird's control.
If a person has direct access to the machine on which Firebird
is running then all bets are off - they can do whatever they
want and nothing is secure. If the person has access to the
file from the network (and there is no reason to allow this)
then even if the database was encrypted (which it's not) it
would be feasible to effectively attack that encryption under
this situation - hence the stipulation that you should not
allow direct access to the database file if you want security.
Having the user/password inside or outside the database has
nothing useful to do with security, being open source doesn't
have much to do with it either.
--
Geoff Worboys
Telesis Computing Pty Ltd
may be appropriate.
Firstly: Lane, it is not clear what you mean by "may have been
compromised" - whether you are speaking of someone having
obtained a copy of the data, or whether someone has been able
to apply unauthorised updates. The former can be achieved via
mechanisms outside the Firebird (or your application) control,
the latter is typically a Firebird or application issue. You
need to specify what you think may have happened to get
anything very useful in the way of responses.
Firebird itself is (at least reasonably) secure within certain
constraints.
One of the common complaints is that, as indicated by ma_golyo,
if a person can gain direct access to the database file then
they can open it on their own system using known a known
password (or version of Firebird that doesn't need one).
However, to gain direct access to the file suggests either
access to the file via the network, or direct access to the
server on which Firebird resides. Either of which are contrary
to a secure design and out of Firebird's control.
If a person has direct access to the machine on which Firebird
is running then all bets are off - they can do whatever they
want and nothing is secure. If the person has access to the
file from the network (and there is no reason to allow this)
then even if the database was encrypted (which it's not) it
would be feasible to effectively attack that encryption under
this situation - hence the stipulation that you should not
allow direct access to the database file if you want security.
Having the user/password inside or outside the database has
nothing useful to do with security, being open source doesn't
have much to do with it either.
--
Geoff Worboys
Telesis Computing Pty Ltd