Subject | Re: SYSDBA and passwords |
---|---|
Author | petesouthwest |
Post date | 2005-02-25T09:14:45Z |
Hi
Thanks for clarifying those issues.
What is the best way of dealing with the creation of a new
user/password? I was thinking something along the lines of:
Try to connect using username/password
Except
begin
create username/password using gsec
connect using username/password
end;
I am not sure how to deal with the potential problems with SYSDBA
and its default password. If I make my app change it, wont that
potentially have an effect on someone else's program, or the
database manager on the system my app is being installed on? Or is
it fair to say that everyone else's app would create their own
usernames/passwords anyway? So my app should just change the
password for SYSDBA?
Thanks again for the advice
Pete
--- In firebird-support@yahoogroups.com, "Adam" <s3057043@y...>
wrote:
Thanks for clarifying those issues.
What is the best way of dealing with the creation of a new
user/password? I was thinking something along the lines of:
Try to connect using username/password
Except
begin
create username/password using gsec
connect using username/password
end;
I am not sure how to deal with the potential problems with SYSDBA
and its default password. If I make my app change it, wont that
potentially have an effect on someone else's program, or the
database manager on the system my app is being installed on? Or is
it fair to say that everyone else's app would create their own
usernames/passwords anyway? So my app should just change the
password for SYSDBA?
Thanks again for the advice
Pete
--- In firebird-support@yahoogroups.com, "Adam" <s3057043@y...>
wrote:
>so
> Hi Pete,
>
> --- In firebird-support@yahoogroups.com, "petesouthwest"
> <petesouthwest@h...> wrote:
> >
>
> > I was intending to change the SYSDBA password from the default
> > that other developers/hackers would not be able to access theam
> user's
> > data, so I have just begun reading about database security. But
> > rather confused. From my understanding of what I have read, thea
> > usernames and passwords for all databases are dealt with by the
> > firebird server, rather than individual databases, and stored in
> > security.fdb.the
> >
>
> 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
> database file is encrypted, how do you prevent them from gettingthe
> private key?that
>
> The only real safe way is to host the database yourself. I hope
> this will change one day, to at least change it to a "not worththe
> effort to hack" level of security.app
>
> > Can someone explain what happens to my app and its associated fb
> > database if an end user changes the SYSDBA password? Surely my
> > will no longer be able to communicate with its database as theapp
> > has been compiled with the default password?SYSDBA).
> >
>
> Yes, your application will need to use a valid user / password to
> connect. This doesn't need to be (and probably shouldn't be
>to
> > Does my app have to create a new user, and use this new username
> > communicate with the database?access
> >
>
> 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
> > to a database could be the solution. The idea behind it is that,have
> > 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
> > access anyway. Some have reported limited success in thisrespect
> byif
> > 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
> > 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