home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / database / oracle / 2544 < prev    next >
Encoding:
Internet Message Format  |  1992-12-16  |  3.1 KB
  1. Path: sparky!uunet!olivea!spool.mu.edu!think.com!paperboy.osf.org!hsdndev!news.cs.umb.edu!pytlik
  2. From: pytlik@ra.cs.umb.edu (Marek Pytlik)
  3. Newsgroups: comp.databases.oracle
  4. Subject: Re: OPS$LOGIN : security hole?
  5. Message-ID: <1992Dec17.015556.29554@cs.umb.edu>
  6. Date: 17 Dec 92 01:55:56 GMT
  7. References: <1992Dec14.222728.13778@oracle.us.oracle.com> <1992Dec15.144220.25349@relay.nswc.navy.mil> <8aT=R#A@engin.umich.edu>
  8. Sender: news@cs.umb.edu (USENET News System)
  9. Organization: University of Massachusetts at Boston, Dept of Math and CS
  10. Lines: 56
  11. Nntp-Posting-Host: ra.cs.umb.edu
  12.  
  13. In article <8aT=R#A@engin.umich.edu> lwk@engin.umich.edu (Lewis W Kellum) writes:
  14. >In article <1992Dec15.144220.25349@relay.nswc.navy.mil> rlarson@nswc-wo.nswc.navy.mil (Ruth Larson) writes:
  15. >>
  16. >>Steve 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. >>>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, this is EXACTLY the case.
  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 account
  40. >>
  41. >>Again, Yes.
  42. >>
  43. >>>We routinely use bogus to define new oracle users, but I am concerned about
  44. >>>security loop holes.  We also use a number of macintosh client products that
  45. >>>use the ops$user with the UNIX password to login.  I am beginning to think
  46. >>>that we should make sure that the Oracle password is the same as the UNIX
  47. >>>password and NOT use bogus for everyone?!@#%               
  48. >>
  49. >>I would NOT suggest making the Oracle password the same as the system password.
  50. >>In many systems the logon password should only be known by the individual
  51. >>user.  However, there's now need for *anyone* to have to know the ops$ password
  52. >>for an individual user - he/she doesn't need to know it, and the DBA can 
  53. >>always reset it without the user even being aware that it has been reset.
  54. >>So use something random, and different for each ops$ account.  I like to pick 
  55. >>a 3 or 4 digit (or larger) number and then spell it out in words.  Example: 
  56. >>two_thousand_three_hundred_eleven.  *Nobody* including you will remember 
  57. >>*that*, and it's pretty hard to guess!
  58. >
  59. >Here's another question: If I know Mr.Schow's unix login id, and the internet 
  60. >hostname of his Oracle server, what keeps me from creating his login id
  61. >on my host and connecting to his ops$ oracle account?  - Woody Kellum
  62.  
  63. sid of the datatabase that is running on that machine. You have to know
  64. that to use connect string.
  65.  
  66. Subject of security hole using OPS$logins and Unix was discussed on this 
  67. newsgroup before, so maybe you want to look for some archives of that 
  68. group. (does such exist?).
  69.