home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / alt / security / 3984 < prev    next >
Encoding:
Text File  |  1992-07-22  |  4.9 KB  |  102 lines

  1. Newsgroups: alt.security
  2. Path: sparky!uunet!paladin.american.edu!darwin.sura.net!jvnc.net!princeton!phoenix.Princeton.EDU!dawagner
  3. From: dawagner@phoenix.Princeton.EDU (David A. Wagner)
  4. Subject: Re: passwd security check
  5. Message-ID: <1992Jul22.221222.6185@Princeton.EDU>
  6. Summary: Two questions about encrypted passwords
  7. Originator: news@ernie.Princeton.EDU
  8. Sender: news@Princeton.EDU (USENET News System)
  9. Nntp-Posting-Host: phoenix.princeton.edu
  10. Organization: Princeton University
  11. References: <1992Jul22.190827.30077@iitmax.iit.edu>
  12. Date: Wed, 22 Jul 1992 22:12:22 GMT
  13. Lines: 87
  14.  
  15. In article <1992Jul22.190827.30077@iitmax.iit.edu> technews@iitmax.iit.edu (Kevin Kadow) writes:
  16. >
  17. >Can somebody point me to a program that will do a security "audit" on the passwd
  18. >file, e.g. reporting (either in a file or as e-mail to the concerned parties)
  19. >when 2 or more accounts have the same password, and other "holes" that would
  20. >not be found by crack?
  21. >
  22.  
  23.     Not sure that such a thing is possible, in the general case.
  24. Lemme consider two cases:  the easier case first, of course :-).  User
  25. A and user B both have the same password, and they *happen* to both have
  26. had their passwords encrypted with the same salt.  Happy day! Now you
  27. can just compare the encrypted passwords - if the encrypted result is
  28. the same, *probably* the unencrypted passwords are the same.  (This is
  29. still an open question, as far as I know.  Almost everyone I've asked
  30. has responded with some variation of "I don't really know, but I don't
  31. think the likelihood of 2 different passwords encrypting to the same
  32. result is very high.")
  33.  
  34.     Ok, so that was the easy case - and the case taken care of by
  35. some ``cut -d: -f4 /etc/passwd | sort | uniq -d''ish type filter.  Now
  36. what happens if User A and user B both have the same password, but
  37. their passwords were encrypted under a different salt?
  38.  
  39.     This is tougher, as far as I know.  (understatement,
  40. understatement :-)   I wonder if it's possible to generate what the
  41. result of encrypting a password with salt X will be, given only the
  42. result of encrypting it with salt Y.
  43.  
  44.     Let me restate.  Lemme call 'E(p,s)' the encryption function,
  45. where 'p' is the password and 's' is the salt.  The easier case asks
  46. if this is possible:
  47.  
  48. [1]    E(p,s) =  E(q,s)        with p,q two different passwords
  49.  
  50. The second (tougher) case asks if a function 'f' exists so that:
  51.  
  52. [2]    f(E(p,s),s,t) = E(p,t)        with s,t two different seeds
  53.  
  54.  
  55.  
  56.     My intuition would suggest that satisfying [2] is at least as
  57. hard as satisfying [1] (if DES isn't broken 1/2 ;-).  Any ideas?
  58.  
  59. >
  60. >R.E. crack- is there a good reason not to simply build a file consisting of the
  61. >crypted and uncrypted entries for an entire dictionary? this would be twice
  62. >as large as just a word dictionary, but much faster than re-crypting...
  63. >
  64.  
  65.     Yeah, as Rob Quinn (rjq@phys.ksu.edu) mentioned in his followup,
  66. for each word you'd have to encrypt it 4096 different ways because of
  67. the salt.  The final encryption of any word is a function of the salt
  68. and that word...  So let's assume there are 100,000 entries in
  69. /usr/dict/words - for each of those words, Crack generates a "perversion"
  70. based on (for example) replacing 'o' with '0', that is, changing 'cool'
  71. to 'c00l'.  For each word there are probably at least 20 different rules
  72. that Crack applies to each word: so you would have to have 100,000 *
  73. 4096 * 20 different encrypted results - that's about 8 billion.  Now
  74. assume 11 characters per encrypted password, and we need almost 100
  75. gigabytes of storage required - that's a bit steep :-)  Notice, too,
  76. that Crack has several different ways of deriving possible passwords
  77. from each user's full name, telephone number, etc - and this kind of
  78. thing you could never store ahead of time.
  79.  
  80.     Now I have *heard* (emphasize the unreliability of this story
  81. here :-) of attacks just like you were talking about with an Exabyte
  82. tape - I would assume the attackers simply left out Crack's 20 different
  83. rules to "pervert" each dictionary entry, so they were only left with
  84. needing 4 or 5 gigabytes of storage... :-)
  85.  
  86.     In short - I don't think it's very feasable.  Though maybe you
  87. *could* do the first 1% of the dictionary words, then the second 1%,
  88. then...   Would you gain anything by doing this?  I don't think you
  89. would unless you have more than 4096 users listed in your /etc/passwd,
  90. though if you had managed to get a list of a few hundred passwd files
  91. somehow, maybe it'd be worth it ;-)
  92.  
  93. [Note to the reader: this used to be an email to Rob Quinn - he corrected
  94. some errors I made, and as I believe some of you on the net might be able
  95. to answer my question, I'm posting here...  I've edited it since sending
  96. to him, but note that he said Crack has about 240 rules instead of the 20
  97. I assumed - so multiply my figure of 100 gigs by about 12 and hold on to
  98. your hats :-]
  99.  
  100. --------------------------------------------------------------------------------
  101. David Wagner            dawagner@phoenix.princeton.edu (or wagner@nisc.jvnc.net)
  102.