Subject | Re: [firebird-support] SYSDBA and passwords |
---|---|
Author | Geoff Worboys |
Post date | 2005-02-25T00:29:26Z |
> I was intending to change the SYSDBA password from theYou certainly should ensure that the SYSDBA password is
> default so that other developers/hackers would not be
> able to access the user's data,
changed - to protect against unwanted network access. This
will protect you database from external/network access
(provided the database file is not available some other way,
such as through a network share). It will NOT protect the
database from anyone with direct access to the database file.
> so I have just begun reading about database security. ButCorrect. Security is server based. Move the database to a
> am rather confused. From my understanding of what I have
> read, the usernames and passwords for all databases are
> dealt with by the firebird server, rather than individual
> databases, and stored in a security.fdb.
different server and it operates under the new server (with
the user names and passwords defined on that new server).
> Can someone explain what happens to my app and its associatedAs already advised, your app should not use SYSDBA if you are
> fb database if an end user changes the SYSDBA password?
> Surely my app will no longer be able to communicate with its
> database as the app has been compiled with the default
> password?
>
> Does my app have to create a new user, and use this new
> username to communicate with the database?
at all concerned about security.
If you create all the database objects using a new user name
then that user name will have effectively unrestricted access
to THAT database (but not necessarily others on the server).
This approach can be convenient if you are not really concerned
about individual access control to the particular database
(which is what it sounds like in your case). If you were to
insist on using the SYSDBA password compiled in your app then
you would destroy any ability to use the FB server for any
other application requiring greater security.
Whatever user/password you do use you probably should provide
the means to allow the password to be changed. (Perhaps by
storing an obsured version in the registry/settings file.)
> Is the SYSDBA meant to be removed after the application hasNo it is not "meant to be removed". The article is only trying
> been installed on the end users system? Wont that stop any
> other applications from communicating with their respective
> databases if they are using the SYSDBA username?
to describe various schemes that people come up with to try and
obtain database file-level security. The article goes on to
explain that this attempt to remove SYSDBA does not really
achieve the desired effect anyway.
Side Note: It is worth mentioning that there are some denial
of service attacks available against Firebird (and the server
on which it is running) if the attacker is able to obtain ANY
valid Firebird user name and password. This is due to some
oversights in the way security has been implemented. eg:
Specifically: Any user authorised by the server can connect
to any database (assuming they know the name of it so that
they can connect). Once they manage to do this they can...
- Change generator values. There is no security checking on
generators, and changing generator values would upset many
database applications.
- Create other database objects and start filling them with
data (thus filling disks and perhaps impacting performance)
If you application makes a user/password combination visible
to potential attackers then these sorts of issues may need to
be considered.
IMO it are these sorts of holes that must be closed in future
versions of FB.
HTH
--
Geoff Worboys
Telesis Computing