| Subject | Re: How secure is Firebird |
|---|---|
| Author | Adam |
| Post date | 2005-10-02T00:34:27Z |
--- In firebird-support@yahoogroups.com, Richard Mace <RichardM@m...>
wrote:
To add to Martijn's comments.
The SYSDBA password is not held in the particular databases FDB file,
but rather another security database. I am not aware of anyway of
extracting the SYSDBA password from the database, because AFAIK, it
isn't even in there in the first place.
But if you get a copy of the fdb file, then you can install the
database to a server where you already know this password, or simply
use the embedded database engine to connect to it, or being an open
source project, even read how the data is stored in the ODS and write
your own interface the allows you to browse it.
So there are a couple of things you can do.
1. Lock down the server. That means creating a user called
FirebirdUser, and giving only that user permissions to access the
Firebird directory and the database file. No-one else needs to see it,
then running the service as that user.
2. The "over the wire" protocol is not encrypted or compressed, so
provides no protection against ethereal or other packet sniffing
tools. A free tool called Zebedee can be used to create a secure
tunnel to the server that can both encrypt and compress the
communications.
3. Firewall, you only need to allow 3050 (or whatever port you use for
Zebedee and events if applicable).
4. Disallow File sharing for the fdb file, they do not need access to
the file over the network.
5. Don't let the users know their own password. Create a UI in your
application for them to manage their password. This can be a wrapper
around gsec. Add some mystery string (and salt) to their password they
type in, and take a hash (SHA-1 is enough), and use the hash as their
password. That way they can't use a tool such as iSQL to run queries,
because they do not know their actual password.
If you need real security, then you need to understand about key
management etc, and if the person you are trying to limit access to is
the administrator of the system, then you are already fighting a lost
battle. A simple key logger will undo any work you do, no matter how
clever your solution is, but otherwise, a hosted solution is the
safest. We use terminal services to deliver our application where
possible, and deny customers access to explorer, iexplore, cmd, mmc,
regedit, taskmgr and several other goodies windows gives you access
to. We use the enviroment settings to automatically launch our
application login screen, and when our application is closed, their
session automatically logs off. Of course it is not bullet proof, but
it is good enough for our requirements.
Adam
wrote:
> Hi,Hi Richard.
> This might sound like a bit of a daft question, but if a user got hold
> of a Firebird 1.52 .fdb file, how secure is the SYSDBA password in it?
> That is, would it take much effort to extract the unknown password?
>
> Thanks
>
> Richard
To add to Martijn's comments.
The SYSDBA password is not held in the particular databases FDB file,
but rather another security database. I am not aware of anyway of
extracting the SYSDBA password from the database, because AFAIK, it
isn't even in there in the first place.
But if you get a copy of the fdb file, then you can install the
database to a server where you already know this password, or simply
use the embedded database engine to connect to it, or being an open
source project, even read how the data is stored in the ODS and write
your own interface the allows you to browse it.
So there are a couple of things you can do.
1. Lock down the server. That means creating a user called
FirebirdUser, and giving only that user permissions to access the
Firebird directory and the database file. No-one else needs to see it,
then running the service as that user.
2. The "over the wire" protocol is not encrypted or compressed, so
provides no protection against ethereal or other packet sniffing
tools. A free tool called Zebedee can be used to create a secure
tunnel to the server that can both encrypt and compress the
communications.
3. Firewall, you only need to allow 3050 (or whatever port you use for
Zebedee and events if applicable).
4. Disallow File sharing for the fdb file, they do not need access to
the file over the network.
5. Don't let the users know their own password. Create a UI in your
application for them to manage their password. This can be a wrapper
around gsec. Add some mystery string (and salt) to their password they
type in, and take a hash (SHA-1 is enough), and use the hash as their
password. That way they can't use a tool such as iSQL to run queries,
because they do not know their actual password.
If you need real security, then you need to understand about key
management etc, and if the person you are trying to limit access to is
the administrator of the system, then you are already fighting a lost
battle. A simple key logger will undo any work you do, no matter how
clever your solution is, but otherwise, a hosted solution is the
safest. We use terminal services to deliver our application where
possible, and deny customers access to explorer, iexplore, cmd, mmc,
regedit, taskmgr and several other goodies windows gives you access
to. We use the enviroment settings to automatically launch our
application login screen, and when our application is closed, their
session automatically logs off. Of course it is not bullet proof, but
it is good enough for our requirements.
Adam