[582] in Kerberos
Re: password checking
daemon@TELECOM.MIT.EDU (Jerome H. Saltzer)
Mon Jan 9 21:09:19 1989
To: sms-dev@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
In-Reply-To: Jennifer Steiner <steiner@ATHENA.MIT.EDU>'s message of Mon, 09 Jan 89 17:56:50 EST
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Jennifer has provided one very good argument against central
checking, but a couple of bogus ideas got mixed in, I think.
The good argument is that Kerberos doesn't have its hands on (and
doesn't want to know about) the personal facts about the user (first
and middle names, phone number, nickname, office number, etc.) that
a good password quality checker would probably use in its tests.
The first bogus idea is that (whether or not the client checks the
string version of the key) Kerberos should do a separate quality
check of the DES key. Apart from checking for all zeros and all
ones, there is no useful quality check for a DES key. Specifically,
for a service key that is allegedly chosen at random, Kerberos can't
tell by looking at a key whether or not it can be easily guessed by
someone who knows that the client used a misguided algorithm to
generate it.
The second bogus idea is that sending keys in string-to-key form
means that you don't have to trust the Kerberos administrator. While
it is true that not sending ASCII form passwords means that the
administrator can't make a list of ASCII passwords, it is still
possible, given only the key form of the password, for the
administrator to compile a list of keys and write a version of kinit
that uses those keys by simply skipping the string-to-key step. I
remain unconvinced that sending the ASCII password to Kerberos is a
significant security exposure.
Jerry
