home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / sci / crypt / 2708 < prev    next >
Encoding:
Internet Message Format  |  1992-07-21  |  2.5 KB
  1. Xref: sparky sci.crypt:2708 comp.security.misc:750
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!wupost!uwm.edu!ogicse!qiclab!leonard
  3. From: leonard@qiclab.scn.rain.com (Leonard Erickson)
  4. Newsgroups: sci.crypt,comp.security.misc
  5. Subject: Re: Crypt should be based on MD5 (was: the Crypt 16 discussion)
  6. Message-ID: <1992Jul21.140600.23632@qiclab.scn.rain.com>
  7. Date: 21 Jul 92 14:06:00 GMT
  8. Article-I.D.: qiclab.1992Jul21.140600.23632
  9. References: <2a510a22@babyoil.ftp.com> <709960260@romeo.cs.duke.edu>   <PMETZGER.92Jul8120712@snark.shearson.com> <21106@rpp386.lonestar.org>   <1992Jul9.035150.3220@qiclab.scn.rain.com> <62451@cup.portal.com>
  10. Reply-To: 70465.203@compuserve.com
  11. Organization: SCN Research/Qic Laboratories of Tigard, Oregon.
  12. Lines: 37
  13.  
  14. ts@cup.portal.com (Tim W Smith) writes:
  15.  
  16. >> But even with this, we got squawks about "why do we need to change
  17. >> passwords every 90 days?" (we couldn't push a shorter interval on them).
  18. >> And we had people who insisted on being able to re-use passwords. 
  19. >> 
  20. >> Unless you can get the users to *care* about security, they aren't
  21. >> going to bother.
  22.  
  23. >Has anyone shown that forcing users to change passwords every so often
  24. >actually makes things more secure?  Isn't frequent changing of passwords
  25. >just going to make it more likely that users will write down the passwords
  26. >somewhere?
  27.  
  28. Well, there *are* reasons why you pretty much *have* to do periodic
  29. changes or accept ever increasing loss of security.
  30.  
  31. We *knew* that people would give out their passwords to other users. Even
  32. though this was very much *against* policy. by changing the passwords we
  33. at least chopped off those "holes" every so often. Note that we were *trying*
  34. to get users to use the "grant" command, which could be used to give 
  35. another account specific access rights in a users files ort directories. 
  36. It was prefffered because ypu can easily *list* who you've given what rights 
  37. to (the TLIST command). 
  38.  
  39. We may have had some problems *due to* the changes. But we know that they
  40. closed the holes at least temporarily. The users weren't doing a "I'll
  41. share my password with Joe", instead it'd be something like Joe saying
  42. "Hey, where's that report, I need it!" and the user giving Joe their 
  43. password instead of loggining in and granting access or copying it to
  44. a directory joe had access to.
  45.  
  46. -- 
  47. Leonard Erickson              leonard@qiclab.scn.rain.com
  48. CIS: [70465,203]             70465.203@compuserve.com
  49. FIDO:   1:105/56     Leonard.Erickson@f56.n105.z1.fidonet.org
  50. (The CIS address is checked daily. The others infrequently)
  51.