On Thu, Jan 31, 2002 at 11:40:43AM -0600, Jacques A. Vidrine wrote:
> On Thu, Jan 31, 2002 at 11:45:00AM -0500, Nicolas Williams wrote:
> > Use pre-auth and shut up.
> 
> Testy today, Nico? :-)

:)

> > (a dictionary attack on an
> > encrypted timestamp is a brute force attack with known plaintext and
> > known ciphertext)
> 
> No.  Dictionary attacks and brute force attacks are very different
> things.  The keyspaces are quite different.  We worry about dictionary
> attacks.  We don't worry so much (yet) about brute force attacks.

Well, let's see: with NIS crypt9) hashes you get 8 x ~5 bits for the
keys. Brute-force searching of 40-bit keys is not terribly difficult and
for most user passwords the NIS crypt() key space is even smaller. I
worry about brute force attacks on NIS crypt().

With Kerberos the amount of entropy in users' passwords can be improved,
but there is a cultural limit to password quality. So it brute force
searches are still problematic. I do maintain that it is more difficult
to get at much ciphertext with Kerberos that you could apply brute force
searchingon unless you can sniff the wire, whereas with NIS you need not
sniff anything to find all the crypt() hashes for a given domain.

> > The question is how difficult is it to cryptanalyze
> > Kerberos, and the answer is that pa-enc-timestamp is not terribly
> > strong, 
> 
> Primarily because the encryption key is derived from a user-selected
> password.

Right.

> > If an attacker
> > can snoop then only good key management can protect you against the
> > attacker's cryptanalysis tools.
> 
> Uh, no.  Better cryptographic protocols can protect you.

Well, both really. I don't care how good the cryptographic protocol is,
key management is always a problem and keys do get "old."

> > Password aging and password quality checks are part of good key
> > management. Ok?
> 
> What you don't seem to understand is that ``We have the technology.''

And there are other areas that have needed attention.

And Microsoft can sell you that technology if you want it (smartcards),
so it is available.

> Using a better preauthentication method, whether it be EKE or SRP
> or PDM or what have you, can make it so that offline (offline!!)
> dictionary attacks are not possible _even in the face of poorly chosen
> passwords_.  And users will always choose poor passwords, even with
> so-called `password quality' checks.  Lazy users are good at finding
> minima.
> 
> Brute force attacks and online dictionary attacks are always possible,
> but far less worrisome.

My original point. PA-ENC-TIMESTAMP pre-auth + switched networks mean
you have to be active (to snoop AS exchanges or to test passwords in AS
exchanges) rather than passive to mount a dictionary attack. As opposed
to NIS where you need not even snoop and where "ypcat passwd" does not
usually raise any flags, red or otherwise.

> Believe it or not (one couldn't tell from this thread ;-) I'm busy
> today, so I think this will be my last post on the subject for now.

Indeed.

> Cheers,
> -- 
> Jacques A. Vidrine <[EMAIL PROTECTED]>                     http://www.nectar.cc/
> NTT/Verio SME           .      FreeBSD UNIX      .        Heimdal Kerberos
> [EMAIL PROTECTED]      .   [EMAIL PROTECTED]   .           [EMAIL PROTECTED]

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.

Reply via email to