Hi Pete,

--- In firebird-support@yahoogroups.com, "petesouthwest"
<petesouthwest@h...> wrote:

>

> I was intending to change the SYSDBA password from the default so
> that other developers/hackers would not be able to access the

user's

> data, so I have just begun reading about database security. But 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.
>

I was going to suggest you to read Geoff's article, but it appears
you have already found it. It is pretty comprehensive and heavy at
times.

In a nutshell, if I have access to your fdb file, I can get your
data. Note that this is not a problem unique to firebird. Even if the
database file is encrypted, how do you prevent them from getting the
private key?

The only real safe way is to host the database yourself. I hope that
this will change one day, to at least change it to a "not worth the
effort to hack" level of security.

> Can someone explain what happens to my app and its associated 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?
>

Yes, your application will need to use a valid user / password to
connect. This doesn't need to be (and probably shouldn't be SYSDBA).

> Does my app have to create a new user, and use this new username to
> communicate with the database?
>

Yes (unless it is SYSDBA)

> Some of this article: http://firebird.sourceforge.net/index.php?
> op=doc&sub=contrib&id=fb_meta_security seems to contradict my
> understanding of what I have read.
> One part says
> "Removing SYSDBA access
> At various times people have suggested that removing SYSDBA access
> to a database could be the solution. The idea behind it is that,
> when the database is moved to a new server where the SYSDBA

password

> is known, it will not help the person because SYSDBA does not have
> access anyway. Some have reported limited success in this respect

by

> creating an SQL role name of SYSDBA and making sure it does not

have

> access to the database objects."
>
> Is the SYSDBA meant to be removed after the application has 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?

The suggested solution Geoff is talking about involves creating a
role called "SYSDBA", giving it no access to anything. This should
confuse any SYSDBA login.

Hope that helps

Adam