[576] in Kerberos
Re: password checking
daemon@TELECOM.MIT.EDU (Jerome H. Saltzer)
Sun Jan 8 22:19:52 1989
To: sms-dev@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
In-Reply-To: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>'s message of Sun, 8 Jan 89 16:48:31 EST
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
> I have a couple of arguments which are against central checking:
>
> 1) It would be nice to be able to allow a service to change its own
> service key.
As Bill observed, the issue of how to arrange for changing a service
key is somewhat orthogonal from that of changing a password.
However, even for a service key there is still a quality issue: is
the new key really random? Since generating really random keys is a
hard problem, whatever procedure one devises for changing service
keys it would probably be advisable for the new service key to be one
produced centrally by the Kerberos key generator.
> 2) There was a proposal made that in a future version of Kerberos, the
> string_to_key algorithm should be modified to include a per-realm
> seed, so that if a user with an identity in more than one realm used
> the same password string for several realms, compromise of one realm
> would not lead to compromise of the user's identity in another realm.
>
> This implies that the KDC should never see the un-hashed password at
> all.
That is an interesting argument. [I assume the proposal might be to
concatenate the realm name with the password before running it
through string-to-key. That would provide a standard way in which my
local library could deal with any Kerberos service.]
The exposure at the KDC is fleeting: the password is available to the
KDC just long enough to quality-check it and string-to-key it. If I
capture a KDC, the only other-realm identities that I could discover
would be for those users who changed their passwords after my
takeover (and who use the same password in the other realm). So the
problem isn't as bad as it sounds, but it is a real one. I guess the
main thrust of this argument is protecting yourself against a
Kerberos administrator who adds code to his KDC to make a clear-text
list of all his customer's passwords as they are registered or
changed.
I'm not sure how to trade that risk against the virtues of central
quality control.
Jerry
