Re: Reject user connect to database via SQL*PLUS ??

From: <rtproffitt_at_my-deja.com>
Date: Tue, 19 Oct 1999 15:36:41 GMT
Message-ID: <7ui368$f83$1@nnrp1.deja.com>

Another approach entirely is one which is used by my friend at a large, major ISP.
Although it takes more planning and thought, it is pretty secure...

The actual password is not the password the user types. (Alternatively, you could alter the userid, but this is more visible by anyone). Say for example you decide to add 'xyz' to any user password. This means that the application must be smart enough to have a change password feature, and a logon box...It must intercept the user's logon and concatenate the characters.

Disadvantages: Takes thought and programming effort. Advantages: Virtually locks out all other forms of connection to Oracle other than through your controlled application.

---

Another approach on another project:
The userid and passwords used on the database are separated and not connected to the user...
(or alternatively, the password only).

When the user logs on, a procedure in a schema, on behalf of a user goes into a small, secret table
(local to that procedure's schema) and converts
the userid/password into a private, controlled userid/password. The user is connected via this. The user never knows how he/she is being connected to database, so the use of SQL/Plus, Access, etc. would fail on logon.
(I thank my friends on the Boeing EMOD project
for this idea).

Robert Proffitt
Beckman Coulter
RTProffitt "AT" beckman "DOT" com

Sent via Deja.com http://www.deja.com/
Before you buy. Received on Tue Oct 19 1999 - 10:36:41 CDT