home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / alt / internet / services / 1552 < prev    next >
Encoding:
Text File  |  1992-11-17  |  1.7 KB  |  40 lines
  1. Newsgroups: alt.internet.services
  2. Path: sparky!uunet!wupost!uwm.edu!zaphod.mps.ohio-state.edu!caen!spool.mu.edu!agate!stanford.edu!CSD-NewsHost.Stanford.EDU!Xenon.Stanford.EDU!aelman
  3. From: aelman@Xenon.Stanford.EDU (Adam Elman)
  4. Subject: Re: TALK (giving away passwords)
  5. Message-ID: <aelman.721967230@Xenon.Stanford.EDU>
  6. Sender: news@CSD-NewsHost.Stanford.EDU
  7. Organization: CS Department, Stanford University, California, USA
  8. References: <MAPPLER.92Nov15211149@titan.ucc.umass.edu> <1992Nov16.215542.5688@nosc.mil>
  9. Date: 17 Nov 92 02:27:10 GMT
  10. Lines: 28
  11.  
  12. wolfgang@nosc.mil (Lewis E. Wolfgang) writes:
  13.  
  14. >I can't speak for other sites, but being a military facility we consider
  15. >giving out a password a security violation.  When a user has an account
  16. >on a system, he/she may have access to information intended only for other
  17. >authorized users of that system.  Authorized users are considered to be
  18. >"friendly" and unlikely to try to gain root access or to cause other 
  19. >troubles.  Thus, by giving away your password you relinquish control
  20. >and responsibility for the correct useage of your account.  
  21.  
  22. >In our context, a user giving away their password would not only loose
  23. >their home account, but we would setup one for them at 
  24. >leavenworth.fed.prison.gov :-)
  25.  
  26. I think this is definitely the policy and reasoning followed by most
  27. sites, including Stanford.  But our penalties are not nearly so
  28. harsh...:-)  Although, in all seriousness, giving others access to
  29. your account may be considered a violation of the Fundamental
  30. Standard, Stanford's highest honor code, so that egregious violation
  31. of this policy can result in pretty severe penalties -- but that's
  32. pretty darn unlikely.  I haven't read the policy document lately...
  33.  
  34. Adam Elman
  35. aelman@cs.stanford.edu
  36.  
  37.  
  38.  
  39.  
  40.