home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / novell / 9648 < prev    next >
Encoding:
Internet Message Format  |  1992-11-19  |  2.4 KB
  1. Path: sparky!uunet!caen!hellgate.utah.edu!cc.usu.edu!jrd
  2. From: jrd@cc.usu.edu (Joe Doupnik)
  3. Newsgroups: comp.sys.novell
  4. Subject: Re: Security Patches - How Secure???     
  5. Message-ID: <1992Nov19.083022.61028@cc.usu.edu>
  6. Date: 19 Nov 92 08:30:22 MDT
  7. References: <1992Nov19.030232.10943@umr.edu>
  8. Organization: Utah State University
  9. Lines: 38
  10.  
  11. In article <1992Nov19.030232.10943@umr.edu>, rfranken@mcs213i.cs.umr.edu (Richard Brett Frankenberger) writes:
  12. > I hate to be the one to start another security discussion here, but inquiring
  13. > minds want to know ... (seriously, I believe Netowrk administrators should
  14. > have access to this information) ...
  15. >  
  16. > Novell recently released patches designed to counteract HACK.EXE.  It appears
  17. > that this will prevent HACK.EXE and anything like it from working.
  18.     <history part omitted>
  19. > What I am looking for here is either:
  20. >  
  21. > (a) a statement that this CAN BE DONE.  (I would not expect details, as
  22. > they could be used by a hacker to gain access, although hacker's will probably
  23. > figure this out before too long); or
  24. >  
  25. > (b) A detailed explanation of why it cannot be done.  There is no danger in
  26. > disclosing protocol details if it won't do hacker any good.  A statement from
  27. > someone simply saying this CANNOT BE DONE doesn't mean much - I would much
  28. > rather have it stand up to the scrutiny of the net.  (Unix and TCP/IP).   
  29. > (And novell has applied for a patent, no there should be no trouble with the
  30. > disclosing of how it works)
  31. >  
  32. > Does anyone have any information in this area?
  33. >  
  34. >       - Brett      (rfranken@cs.umr.edu)
  35. -----------------
  36.     Rather than expend lots of bandwidth on inconclusive results may
  37. I recommend reading up on Kerberos, part of the MIT Project Athena, as
  38. a start. There is no 100% guaranteed, foolproof, absolute, "statement", 
  39. way of preventing spoofing or other break-ins; people are deviously clever.
  40. Don't forget to shred and burn your user's scrap paper, check their picture
  41. idents, voice prints, telephone lines, leakage of video display signals
  42. (Tempest qualification) and so on. Certainly never put info on a Unix machine 
  43. because it leaks like a sieve. And watchout for spoof servers (while the real 
  44. ones are unplugged) and bogus backup tapes. Kerberos makes a good try at 
  45. net.security, but it is not without cost and pain. Meanwhile, ordinary users 
  46. are the largest security holes, by far. In other words, if the game is
  47. security then view the whole situation.
  48.     Joe D.
  49.