home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / database / oracle / 2528 < prev    next >
Encoding:
Text File  |  1992-12-16  |  2.5 KB  |  60 lines
  1. Newsgroups: comp.databases.oracle
  2. Path: sparky!uunet!caen!lwk
  3. From: lwk@engin.umich.edu (Lewis W Kellum)
  4. Subject: OPS$LOGIN :security hole? 
  5. Message-ID: <8aT=R#A@engin.umich.edu>
  6. Date: Wed, 16 Dec 92 12:45:15 EST
  7. Organization: University of Michigan Engineering, Ann Arbor
  8. References: <1992Dec11.235533.18673@pmafire.inel.gov> <1992Dec14.222728.13778@oracle.us.oracle.com> <1992Dec15.144220.25349@relay.nswc.navy.mil>
  9. Nntp-Posting-Host: gail.engin.umich.edu
  10. Lines: 48
  11.  
  12. In article <1992Dec15.144220.25349@relay.nswc.navy.mil> rlarson@nswc-wo.nswc.navy.mil (Ruth Larson) writes:
  13. >
  14. >Steve Schow writes:
  15. >>We routinely use the OPS$LOGIN feature of Oracle for all of our users.  This
  16. >>way they don't have to worry about anything once they are logged onto the
  17. >>UNIX machine.  They just type program / to run it with their UNIX login info.
  18. >
  19. >>Question:  
  20. >
  21. >>When we create a new user as follows:
  22. >
  23. >>    grant connect to ops$user identified by bogus;
  24. >
  25. >>and we actually use the word 'bogus' as the oracle password.
  26. >
  27. >>Does this mean that user ops$user could login to Oracle with either
  28. >>the /, which would use his UNIX login info, or with 'bogus' as the
  29. >>password?
  30. >
  31. >Yes, this is EXACTLY the case.
  32. >
  33. >>Could a user go into sql*plus with any convienient name and type
  34. >
  35. >>    connect ops$user/bogus
  36. >
  37. >>to get into that user's oracle account
  38. >
  39. >Again, Yes.
  40. >
  41. >>We routinely use bogus to define new oracle users, but I am concerned about
  42. >>security loop holes.  We also use a number of macintosh client products that
  43. >>use the ops$user with the UNIX password to login.  I am beginning to think
  44. >>that we should make sure that the Oracle password is the same as the UNIX
  45. >>password and NOT use bogus for everyone?!@#%               
  46. >
  47. >I would NOT suggest making the Oracle password the same as the system password.
  48. >In many systems the logon password should only be known by the individual
  49. >user.  However, there's now need for *anyone* to have to know the ops$ password
  50. >for an individual user - he/she doesn't need to know it, and the DBA can 
  51. >always reset it without the user even being aware that it has been reset.
  52. >So use something random, and different for each ops$ account.  I like to pick 
  53. >a 3 or 4 digit (or larger) number and then spell it out in words.  Example: 
  54. >two_thousand_three_hundred_eleven.  *Nobody* including you will remember 
  55. >*that*, and it's pretty hard to guess!
  56.  
  57. Here's another question: If I know Mr.Schow's unix login id, and the internet 
  58. hostname of his Oracle server, what keeps me from creating his login id
  59. on my host and connecting to his ops$ oracle account?  - Woody Kellum
  60.