Subject | Firebird Security |
---|---|
Author | Johan van Zyl |
Post date | 2004-04-05T19:23:29Z |
From Clarion NG
Doug,
You don't misunderstand. The problem is that the tool and the script to
build the DB generally use the same user ID which be later used to connect
from the client application. That should not be the case. It's very easy,
with an SQL script, to create and delete users.
Like for everything, there is thousands ways to skin the same cat, but there
is no reasons to have (admitting we are in the MS SQL context) a "server
wide" user connected to your application. The least that should be done is
to create a database specific user, with no administrative rights, and have
the ODBC connection created of this user, for generic application use, and
change via script (or better, delete and re-create with another name) the
"administrator" login.
Bernard
JVZ Systems CC Customised Software - When it needs
to fit like a glove
Johan van Zyl
Owner JVZ Systems CC
PO Box 3469
Somerset West
7129
johan@... http://www.jvz.co.za tel:
fax:
mobile: +27 21 851 7205
+27 21 852 2387
082 875 4238
Signature powered by Plaxo Want a signature like this?
Add me to your address book...
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.648 / Virus Database: 415 - Release Date: 2004-03-31
[Non-text portions of this message have been removed]
Doug,
> When a dev creates an ODBC DSN and provides the passwords to it., I knowsome
> that the password is masked and unviewable by others. Taking the db to
> other computer would be worthless.created?
>
> But can't a dev simply place a db manager tool directly on the pc with the
> already created DSN to gain full access?
>
> Is my misunderstanding based on the fact that I should be passing the
> password at runtime and not storing it when the ODBC connection is
You don't misunderstand. The problem is that the tool and the script to
build the DB generally use the same user ID which be later used to connect
from the client application. That should not be the case. It's very easy,
with an SQL script, to create and delete users.
Like for everything, there is thousands ways to skin the same cat, but there
is no reasons to have (admitting we are in the MS SQL context) a "server
wide" user connected to your application. The least that should be done is
to create a database specific user, with no administrative rights, and have
the ODBC connection created of this user, for generic application use, and
change via script (or better, delete and re-create with another name) the
"administrator" login.
Bernard
JVZ Systems CC Customised Software - When it needs
to fit like a glove
Johan van Zyl
Owner JVZ Systems CC
PO Box 3469
Somerset West
7129
johan@... http://www.jvz.co.za tel:
fax:
mobile: +27 21 851 7205
+27 21 852 2387
082 875 4238
Signature powered by Plaxo Want a signature like this?
Add me to your address book...
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.648 / Virus Database: 415 - Release Date: 2004-03-31
[Non-text portions of this message have been removed]