On Thu, Jan 31, 2002 at 08:15:13AM -0600, Jacques A. Vidrine wrote: > On Thu, Jan 31, 2002 at 08:41:40AM -0500, Nicolas Williams wrote: > > NIS is public. Kerberos is not. With NIS you just query the NIS servers > > and you've got the hashes to work with. With Kerberos you must sniff the > > wire to gather ciphertext for cryptanalysis. > > Only if the KDC is correctly configured, which it probably is not. > MIT, Heimdal, and Windows 2000 implementations default with no pre- > authentication turned on.[1] Also, even if preauthentication is on, > one can still abuse the TGS exchange to get the material needed for a > dictionary attack, unless the KDC administrator has been careful.
Come now, turning on pa-enc-timestamp pre-auth is very easy and mostly transparent. Switching to stronger pre-auth types is harder; replacing NIS is harder still. > > In the real world today most LANs are switched and corporate WANs tend > > to be encrypted. This makes it rather difficult to snoop on the wires. > > (In the Internet, as opposed to the intranet, WANs are not often > > encrypted though.) > > So what? ARP poisoning can be used to steal the traffic even on > switched networks. The most serious attacks come from the inside, > where VPNs and other measures do nothing to reduce the risk. With switched networks an attacker has to try some active attacks to snoop. With NIS they need only "ypcat passwd" once, which will almost certainly go undetected, and go offline. With Kerberos attackers have to snoop the right network/hosts at the right time or, if pre-auth is not required, they have to perform AS-REQs for the principals they wish to attack *and* the must know the names of those principals a priori. So with Kerberos the attacker can't try the equivalent of "ypcat passwd" without risking detection (or even at all since the attacker would have to know all the user principal names independently) and is very unlikely to be able to snoop AS exchanges for many users, and if pre-auth is turned on then they can't even accumulate ciphertext by actively trying AS-REQs. > > So in the real world an attacker has to be more active to perform > > dictionary attacks on Kerberos than on NIS. > > Yes, a little more. A lot more. See above. [...] > We need SRP or PDM as a `preauthentication'[2] method. It has been > mentioned that John Brezak and Ken Raeburn are working on an I-D for > one or both of these. Let's hope they produce one soon! I don't understand your second footnote. > Active (online) dictionary attacks are easy to detect and are not a > real risk, IMHO. Right, and with Kerberos you force the attacker to be far more active than with NIS. Ergo Kerberos is significantly stronger than NIS wrt weak passwords. And because of its pre-auth extensibility, the ability to perform password quality checks when users change their passwords and the ability to enforce password aging, Kerberos is really much stronger and has a much longer useful life than NIS, which is really past its useful life now. > Cheers, > -- > Jacques A. Vidrine <[EMAIL PROTECTED]> http://www.nectar.cc/ > NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos > [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] > > [1] How do you tune W2K to require preauthentication? > > [2] Neither actually provide preauthentication. Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.
