home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / database / oracle / 2613 < prev    next >
Encoding:
Internet Message Format  |  1992-12-22  |  2.1 KB
  1. Path: sparky!uunet!spool.mu.edu!uwm.edu!psuvax1!hsdndev!dartvax!kip-sn-36.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-221292113528@kip-sn-36.dartmouth.edu>
  6. Date: 22 Dec 92 16:40:53 GMT
  7. References: <1992Dec14.200952.22697@netcom.com> <24727@suned1.Nswses.Navy.MIL>
  8. Sender: news@dartvax.dartmouth.edu (The News Manager)
  9. Followup-To: comp.databases.oracle
  10. Organization: Dartmouth College
  11. Lines: 46
  12.  
  13. In article <24727@suned1.Nswses.Navy.MIL>, lev@ipxed5.nswses.navy.mil
  14. (Lloyd E Vancil) wrote:
  15. > 
  16. > In article <1992Dec14.200952.22697@netcom.com> sjs@netcom.com (Stephen Schow) writes:
  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. [stuff omitted]
  30. > 
  31. > >Could a user go into sql*plus with any convienient name and type
  32. > >
  33. > >    connect ops$user/bogus
  34. > >
  35. > >to get into that user's oracle accoun
  36. > 
  37. > 
  38. > Emphatically YES
  39. > 
  40. > 
  41. > This is a known security hole in the OPS$ user under oracle 6.. 
  42. [stuff omitted]> 
  43. > Since the OPS$ password need only be used once, in the
  44. > grant command, the dba should be free to use any valid
  45. > password, as long as it follows 2 conventions
  46. > 1. the dba should be THE ONLY PERSON TO KNOW IT.
  47. > 2. each one is unique (within reason here folks)
  48.  
  49. I disagree with #1.  There is no reason for the dba to know these
  50. passwords, either.  If a DBA really needs to know somebody's password, they
  51. can always
  52. change it to something known, then change it back.
  53.  
  54. You can use a script to set the password to a random value.  Or, you can
  55. use the VALUES clause to set the encoding of the password, so that the
  56. actual password is not known by anyone.
  57.  
  58. Glad to hear this is fixed in ORACLE 7.
  59.