home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / security / misc / 842 < prev    next >
Encoding:
Internet Message Format  |  1992-07-22  |  4.2 KB

  1. Xref: sparky comp.security.misc:842 alt.security:4027 comp.unix.ultrix:5928
  2. Path: sparky!uunet!mcsun!uknet!ox-prg!nnhost!pcl
  3. From: pcl@oxford.ac.uk (Paul Leyland)
  4. Newsgroups: comp.security.misc,alt.security,comp.unix.ultrix
  5. Subject: Re: Problem with npasswd??
  6. Message-ID: <PCL.92Jul28114638@black.oxford.ac.uk>
  7. Date: 28 Jul 92 10:46:38 GMT
  8. References: <PCL.92Jul27140810@black.oxford.ac.uk>
  9.     <1992Jul27.184324.14697@hubcap.clemson.edu>
  10. Sender: news@comlab.ox.ac.uk
  11. Organization: Oxford University Computing Service, 13 Banbury Rd, Oxford, OX2
  12.     6NN
  13. Lines: 75
  14. In-reply-to: hubcap@hubcap.clemson.edu's message of 27 Jul 92 18:43:24 GMT
  15.  
  16. In article <1992Jul27.184324.14697@hubcap.clemson.edu> hubcap@hubcap.clemson.edu (System Janitor) writes:
  17.  
  18. > Unless I am mistaken, npasswd doesn't check for everything crack does.
  19.  
  20. You are correct.
  21.  
  22. > Even dropping the time consuming crypt part, it seems like it would
  23. > take an unacceptable amount of time to change your password if it were 
  24. > checked against, say, an 800,000 word dictionary with 300 transmogrification
  25. > rulesets.
  26.  
  27. I don't know.  I could experiment, I suppose.  Looking up a word in a
  28. 800k entry dictionary only takes about 30% more time than looking it
  29. up in the 25k entry /usr/dict/words.  (A binary search is used, on the
  30. assumption that the dictionary is sorted, so we're comparing 2**20
  31. against 2**15: 20/15 = 1.33).  Some rulesets could be dismissed
  32. without doing the dictionary check.  For instance "append 2" will fail
  33. if the candidate does not end in 2.  I suspect that full Crack testing
  34. would not greatly increase checking time if optimisations like this
  35. were included.
  36.  
  37. > The point is, even if you use npasswd, a cracker will still get some of
  38. > your passwords. So what if they only get 10 instead of 200, they'll still
  39.  
  40. In my experience, the efficacy of Crack drops to near zero when it has
  41. been used to crack a system's passwords *and the broken accounts are
  42. disabled*.  Users really do learn to choose Crack-resistant passwords
  43. if they are required to come in with proof of identity before they can
  44. use their account again.  Npasswd helps them to choose Crack-resistant
  45. passwords.
  46.  
  47. In my experience, a naive Unix site will have 20-30% guessable
  48. passwords.  A Crack- and npasswd -free site, but otherwise fairly
  49. security concious will yield 10-15%.  After the first iteration of
  50. Crack and account disabling, I found four passwords out of several
  51. hundred -- around 1%.  After two iterations I didn't break a single
  52. account.
  53.  
  54. > have some userids from which to launch their nefarious plans.
  55. > So, aren't you fooling yourself to think that npasswd like schemes 
  56. > enhance your system security enough to make them worthwhile? 
  57.  
  58. I don't think so.  It is a relatively cheap addition to password
  59. security.  Admittedly, it isn't perfect; nothing in this life is.
  60.  
  61. However, it has two important benefits.  First, it ensures that the
  62. simple Crack rules won't work.  Minor benefit, as one can always
  63. re-order the rules to do the bizarre ones first.
  64.  
  65. Secondly, and much more importantly in my view: it gets the user to
  66. *think* about password security.  If forced to use non-trivial
  67. passwords, people tend to become quite creative.  They also tend to
  68. carry this creativity to other systems where it is not strictly
  69. ncessary, but still desirable.
  70.  
  71. > I realize there is a need for this kind of security, and of course, I
  72. > don't have the right answer. But it doesn't seem like npasswd is it. 
  73. > Discussion?
  74.  
  75. Npasswd does *not* solve all of life's problems.  It is a useful tool;
  76. nothing more.  Shadow passwords, password aging and other such
  77. techniques are also useful tools.  People who believe they can solve
  78. the security problem are deluding themselves.  The best we can do with
  79. current technology is to increase the cost/benefit ratio for crackers,
  80. to the point where it is (probably) not worth the effort, without
  81. increasing it too much for authorised users.  What "too much" means
  82. depends strongly on local circumstances.
  83.  
  84. Paul
  85.  
  86. --
  87. Paul Leyland <pcl@oxford.ac.uk>          | Hanging on in quiet desperation is
  88. Oxford University Computing Service      |     the English way.
  89. 13 Banbury Road, Oxford, OX2 6NN, UK     | The time is come, the song is over.
  90. Tel: +44-865-273200  Fax: +44-865-273275 | Thought I'd something more to say.
  91.