Re: Question about OPS$LOGIN and Oracle Passwords

In article <1992Dec14.200952.22697_at_netcom.com>, sjs_at_netcom.com (Stephen Schow) wrote:
>
> We routinely use the OPS$LOGIN feature of Oracle for all of our users. This
> way they don't have to worry about anything once they are logged onto the
> UNIX machine. They just type program / to run it with their UNIX login info.
>
> Question:
>
> When we create a new user as follows:
>
> grant connect to ops$user identified by bogus;
>
> and we actually use the word 'bogus' as the oracle password.
>
> Does this mean that user ops$user could login to Oracle with either
> the /, which would use his UNIX login info, or with 'bogus' as the
> password?

Yes. They could login using ops$user/bogus
>
> Could a user go into sql*plus with any convienient name and type
>
> connect ops$user/bogus
>
> to get into that user's oracle accoun

Yes. At least this is true on VMS.

Why did you have to ask this on the net? Couldn't you just try it and see?  I hesitated to respond so publically, but decided you had left yourself fairly open to attack already.

> We routinely use bogus to define new oracle users, but I am concerned about
> security loop holes. We also use a number of macintosh client products that
> use the ops$user with the UNIX password to login. I am beginning to think
> that we should make sure that the Oracle password is the same as the UNIX
> password and NOT use bogus for everyone?!_at_#$%^

Yes. Using the Unix password is a reasonable idea - especially if you have a lot of Mac clients.

For people who *never* need to use the ORACLE password, we use:

   grant connect to ops$user identified by values 'bogus';

This set the *encoded* password to "bogus". This is quite secure, because even if someone finds out the encoding, they are not likely to figure out what produces that encoding. We do this using the user's SSN, so a DBA can match to our employee tables. Received on Tue Dec 15 1992 - 01:46:29 CET