On Thu, Jan 31, 2002 at 12:04:53PM -0200, Andreas Hasenack wrote: > Em Thu, Jan 31, 2002 at 08:41:40AM -0500, Nicolas Williams escreveu: > > 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. > > One of the premises of kerberos was to make sniffing useless. It's not > useless anymore.
> Also, I can also just query the kerberos server just like NIS if > preauthentication is not in place. In the real world folks use pre-auth. This is a configuration issue. NIS is open period and the there is no way about it. You can't tell if a "ypcat passwd.byname" was legitimate. But with Kerberos you can detect an active attack where an attacker is doing many AS-REQs to collect tickets on which to run dictionary attacks, and that can't be done anyways if you require pre-auth. > > 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. > > Not anymore, with tools such as dsniff and arpspoof it's really simple. > They even have autoconf and nice manpages :) Yes, but you're forcing the attacker to be more active and so you can try to detect her. > > Also, Kerberos is extensible with respect to pre-authentication. It is > > This is very nice, and one of the solutions pointed out in the paper. And it's possible because Kerberos was designed with extensible pre-auth in mind. So there's nothing wrong with Kerberos, see? You can take issue with sites that do not require pre-auth and you can take issue with the good old pa-enc-timestamp, but Kerberos itself is just fine. And you have an upgrade path for new pre-auth types, whereas with NIS the only upgrade is to switch technologies altogether (yes, you can switch to other hash types, but that would only slow down the passive dictionary attacker). > Of curse NIS doesn't support this and never will. The comparison doesn't go > that far. But the preauth most of us have right now is with timestamps, > I guess. Which can be attacked in the same way, it's a known structure > inside the packet and encrypted with the user's password. IIRC, Microsoft supports smartcard pre-auth. MIT krb5 has some generic otp/challenge-response code (SAM) and I believe there are patches (to MIT krb5 1.1.1) floating around to enable SecurID pre-auth. Heimdal krb5 has OTP support. If you're so concerned, write patches to MIT and/or Heimdal to add support for SRP pre-auth. Also, you can implement password quality checks at the KDC and you can force password aging as mitigation for snoop+dictionary attacks on weak passwords. 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.
