[593] in Kerberos

home help back first fref pref prev next nref lref last post

Re: password checking

daemon@TELECOM.MIT.EDU (Jerome H. Saltzer)
Wed Jan 11 12:03:35 1989

To: Jennifer Steiner <steiner@ATHENA.MIT.EDU>
Cc: kerberos@ATHENA.MIT.EDU, sms-dev@ATHENA.MIT.EDU
In-Reply-To: Jennifer Steiner <steiner@ATHENA.MIT.EDU>'s message of Wed, 11 Jan 89 09:55:10 EST
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>

Jennifer,

Both of your points are well taken.  What I was trying to suggest
when I used the term "bogus" to describe the earlier argument was
that there isn't really any way to significantly reduce the huge
exposure that is intrinsic in trusting the Kerberos administrator to
begin with.  Eliminating the ASCII password nibbles that exposure
down a little, but noone should be confused into thinking that the
administrator is then unimportant.  For purposes of the larger
discussion, I guess the question comes down to how to trade that
small nibbling at the exposure against the opportunity to reduce
other exposures by having central quality control.

So far, I find that Bill's observation that Kerberos doesn't have its
hands on the personal information necessary for good password quality
checks to be the real show-stopper for central checking.  My reaction
at this point is to have the {register, passwd} client do the quality
checks based on personal information, send only the string-to-key
version to Kerberos, and add an option to the protocol that asks
Kerberos to reject the key if it is the same as any of the previous
N for this user.  (N = 3?)

					Jerry

home help back first fref pref prev next nref lref last post