home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / database / oracle / 2508 < prev    next >
Encoding:
Internet Message Format  |  1992-12-14  |  2.4 KB
  1. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!spool.mu.edu!uwm.edu!ogicse!hsdndev!dartvax!kip-sn-16.dartmouth.edu!user
  2. From: carl.pedersen@dartmouth.edu (L. Carl Pedersen)
  3. Newsgroups: comp.databases.oracle
  4. Subject: Re: Question about OPS$LOGIN and Oracle Passwords
  5. Message-ID: <carl.pedersen-141292193658@kip-sn-16.dartmouth.edu>
  6. Date: 15 Dec 92 00:46:29 GMT
  7. Article-I.D.: kip-sn-1.carl.pedersen-141292193658
  8. References: <1992Dec14.200952.22697@netcom.com>
  9. Sender: news@dartvax.dartmouth.edu (The News Manager)
  10. Followup-To: comp.databases.oracle
  11. Organization: Dartmouth College
  12. Lines: 50
  13.  
  14. In article <1992Dec14.200952.22697@netcom.com>, sjs@netcom.com (Stephen
  15. Schow) wrote:
  16. > 
  17. > We routinely use the OPS$LOGIN feature of Oracle for all of our users.  This
  18. > way they don't have to worry about anything once they are logged onto the
  19. > UNIX machine.  They just type program / to run it with their UNIX login info.
  20. > 
  21. > Question:  
  22. > 
  23. > When we create a new user as follows:
  24. > 
  25. >     grant connect to ops$user identified by bogus;
  26. > 
  27. > and we actually use the word 'bogus' as the oracle password.
  28. > 
  29. > Does this mean that user ops$user could login to Oracle with either
  30. > the /, which would use his UNIX login info, or with 'bogus' as the
  31. > password?
  32.  
  33. Yes.  They could login using ops$user/bogus
  34. > 
  35. > Could a user go into sql*plus with any convienient name and type
  36. > 
  37. >     connect ops$user/bogus
  38. > 
  39. > to get into that user's oracle accoun
  40.  
  41. Yes.  At least this is true on VMS.
  42.  
  43. Why did you have to ask this on the net?  Couldn't you just try it and see?
  44.  I hesitated to respond so publically, but decided you had left yourself
  45. fairly open to attack already.
  46.  
  47. > We routinely use bogus to define new oracle users, but I am concerned about
  48. > security loop holes.  We also use a number of macintosh client products that
  49. > use the ops$user with the UNIX password to login.  I am beginning to think
  50. > that we should make sure that the Oracle password is the same as the UNIX
  51. > password and NOT use bogus for everyone?!@#$%^
  52.  
  53. Yes.  Using the Unix password is a reasonable idea - especially if you have
  54. a lot of Mac clients.
  55.  
  56. For people who *never* need to use the ORACLE password, we use:
  57.  
  58.    grant connect to ops$user identified by values 'bogus';
  59.  
  60. This set the *encoded* password to "bogus".  This is quite secure, because
  61. even if someone finds out the encoding, they are not likely to figure out
  62. what produces that encoding.  We do this using the user's SSN, so a DBA can
  63. match to our employee tables.
  64.