| Subject | Re: [ib-support] IB Logon |
|---|---|
| Author | Paul Schmidt |
| Post date | 2001-11-30T14:13:11Z |
On 30 Nov 2001, at 0:36, Dion wrote:
1) Maintain the users in a separate table and have the application
log in as a user known only to the database. In this case you
should look at obtaining one of the encryption routines, and store
the username and password in the application in an encrypted
manner.
2) Add each user to the database, with no security, and then when
the application starts login as SYSDBA adjust the security to what
you need for the application The problem with this is that you need
to be able to "restore" the security when the application ends,
because some users may want to use the database in other ways.
This could leave you with security holes, if the application crashes.
3) Add each user with the security they need for the application,
but mangle the usernames, so for example Paul might be stored in
the database as user $a@5, the login routine knows how to
mangle the username typed in the same manner, so it can
authenticate the user using the same method. If the user needs to
use the database for other things, they have a separate login for
non-application access, even SYSDBA might not know how to un-
mangle a name.
4) Same as three but without the mangling, this could lead to the
most security problems, in that a user who has wide open security
could in fact do damage to the database with a tool like IBConsole.
I think method 3 is the most secure, depending on how you mangle
the names. 1 is the next secure if you encrypt the username and
password properly, then 2 then 4.
Paul
Paul Schmidt
Tricat Technologies
paul@...
www.tricattechnologies.com
> Hi All,There are four schools of thought, you have to pick one...
>
> Has anybody been able to securely allow a DBA to administer user
> rights seperately from IB(or any other DB for that matter). What I
> mean is storing user rights in a seperate table. This means that the
> logon names are not save to IB system tables. The problem I found is
> hiding the initial app logon user name and password. Where do you hide
> the user name and password the app needs to initially logon in order
> to get access to the other user table in order to authenticate user
> access, in a secure fashion?
>
> Will burying it in the app have to do?
>
1) Maintain the users in a separate table and have the application
log in as a user known only to the database. In this case you
should look at obtaining one of the encryption routines, and store
the username and password in the application in an encrypted
manner.
2) Add each user to the database, with no security, and then when
the application starts login as SYSDBA adjust the security to what
you need for the application The problem with this is that you need
to be able to "restore" the security when the application ends,
because some users may want to use the database in other ways.
This could leave you with security holes, if the application crashes.
3) Add each user with the security they need for the application,
but mangle the usernames, so for example Paul might be stored in
the database as user $a@5, the login routine knows how to
mangle the username typed in the same manner, so it can
authenticate the user using the same method. If the user needs to
use the database for other things, they have a separate login for
non-application access, even SYSDBA might not know how to un-
mangle a name.
4) Same as three but without the mangling, this could lead to the
most security problems, in that a user who has wide open security
could in fact do damage to the database with a tool like IBConsole.
I think method 3 is the most secure, depending on how you mangle
the names. 1 is the next secure if you encrypt the username and
password properly, then 2 then 4.
Paul
Paul Schmidt
Tricat Technologies
paul@...
www.tricattechnologies.com