home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / protocol / kerberos / 659 < prev    next >
Encoding:
Text File  |  1992-09-03  |  2.2 KB  |  58 lines
  1. Newsgroups: comp.protocols.kerberos
  2. Path: sparky!uunet!stanford.edu!news
  3. From: bagate!socrates!bf4grjc (Ravi Ganesan (301) 595-8439)
  4. Subject: Re: New User Accounts
  5. Message-ID: <9209031409.AA00547@ramanujam.bell-atl.com>
  6. Sender: news@shelby.stanford.edu (USENET News System)
  7. Reply-To: socrates!socrates.bell-atl.com!ravi
  8. Organization: Internet-USENET Gateway at Stanford University
  9. References: <53920903103935.0003858921NA3EM@mcimail.com>
  10. Date: Thu, 3 Sep 1992 14:09:06 GMT
  11. Lines: 45
  12.  
  13. > 
  14. > Ganesan writes:
  15. > 
  16. > >What problem does it NOT solve? 
  17. > >Type 2. Password weakness problems:
  18. > > - password guessing 
  19. > > - dictionary attacks
  20. > 
  21. > >From the Kerberos class that I took at spring INTEROP, it would seem that the
  22. > dictionary in v5 will pretty much stop these two.
  23. >
  24. Observe that there is a trade off situation in using difficult passwords, 
  25. especiailly when they change often due to password aging, and when a user 
  26. has accounts on several systems which as yet cannot share authentication. 
  27. i.e. the harder the password, the more likely the user is to write it down.
  28.  
  29. Dictionary attacks can eb stopped using the protocls developed by li Gong et 
  30. al, and by Bellovin & Merrit. Note that the latter necessitates the use 
  31. of public-key, and both have (probably acceptable) an overhead.
  32.  
  33. > 
  34. > Nothing will stop intentional password sharing.  Even with a SecureID.  It is
  35. > just more limited with SecureID.
  36. > 
  37.  
  38. With a token authenticator, a physical device needs to change hands for 
  39. password sharing can take place, which in general would require the complicity
  40. of the person doing the sharing, which can be audited. 
  41.  
  42. While I'm sure sharing can/will still occur, it is FAR MORE limited. Nothing 
  43. works like the detterrent of being resonsible for your actions! 
  44.  
  45. Ravi
  46. -- 
  47.  
  48.  
  49. *******************************************************************************
  50.  
  51. Ravi Ganesan                            e-mail: ravi@socrates.bell-atl.com
  52. IS SAS Corporate Network Planning       v-mail: (301) 595-8439
  53. Bell Atlantic                           Fax:    (301) 595-1341
  54.  
  55. Note: If your e-mail reply to me bounces, try sending it explicitly to 
  56. ravi@socrates.bell-atl.com instead of using the 'reply' feature.
  57. ******************************************************************************
  58.