MD5 passwords possible with Kerberos?

[Marcus Watts]

nijsure at cs.unt.edu (Sandeep) writes:
> Hi all,
> 
> I am kinda new to Kerberos, but I have read that one of the biggest
> drawbacks of Kerberos is that the passwords need to be stored
> cleartext on the master server, a BIG security risk..
> 
> Just like Unix passwords are never stored cleartext, but always
> hashed, why not do the same thing with Kerberos? Store MD5 passwords
> on the master server, and use them for encrypting the TGT. So the
> Kerberized login will first compute the MD5 hash, and then decode the
> initial TGT.
> 
> Is this already done in Kerberos? if yes, what is the version that
> supports this?

The MIT KDC does not store passwords in the clear.  It stores keys
derived via a one-way algorithm from the user's password.  For further
security, these keys are also encrypted once more using a "master
secret" key, which can be stored offline if desired.  The "master secret"
stuff is all described in the kerberos documentation - administration and
installation.

In kerberos, the one-way algorithm is called the "string to key" function.
I believe current versions of MIT support 3 basic "string to key" algorithms,
which could be called "des", "afs", and "n-fold" (used for des3).
All of these have theoretical disadvantages.  It's been proposed to use
pkdbf2 (from PKCS #5) with AES - which is sorta based on the MD5 Unix
crypt function.  That has its own issues.  All of these issues pale
in comparison to some much more fundemental problems with using Kerberos
securely - while this is a good theoretical area to investigate, if
you're interested in practical security there's a bunch of other things
that are *far* more important to solve first.

Here is an incomplete list of weaknesses that you might find more useful
to consider:
(1) Most production kerberos realms still use regular DES and no preauth.
	This means they should not be used to protect any secret
	worth more than $100,000.
(2) If you can somehow compromise an operational KDC, you can
	very likely get a copy of everyone's key.  If you know the key,
	you don't *need* to know the password; the key is good enough
	to impersonate the person.  It is *MUCH* more important to
	protect a KDC key database than it is to protect a regular
	Unix password database.  Fortunately, it is also easier to
	do this, because a KDC should not be accessible by regular
	users and should be providing as few services as possible.

	The practical use of the "master secret" is to make kerberos
	database backups useless to an attacker.

	There *are* ways to make even complete knowlege of what's in
	a KDC database "less" useful.  Stanford's SRP is one attempt
	to do this.  There are some computational scaling issues to
	doing this in a large KDC.
(3) Most humans can only remember a plaintext password containing
	about 40 bits of entropy.  Even using DES3 won't fix this
	problem.  Preauth with some additional secret is probably the
	only real fix for this.  Some people claim additional computational
	complexity in the string to key function will fix this, but I think
	this is only a placebo -- see (6).
(4) It would be worth changing the key for krbtgt and other important
	security principals on a regular basis.  This is especially
	important for DES.  I don't know of any simple way to make this
	automatically happen in MIT K5.  This is one of the areas
	where Transarc's kaserver was actually stronger.
(5) A crucial weakness in many security systems is the random number
	generator.  MIT K5 has gotten better, but I don't know that this
	is entirely fixed yet.
(6) Salts have some interesting properties.  In Unix, the salt is generally
	regarded as a "secret", which can be securely commmunicated to
	the login application.  In Kerberos, the salt is public
	information.  Worse yet, the client doesn't generally have any
	good way to securely acquire the salt, which means an active
	attacker can supply bogus salt.  This means the active attacker
	can very likely dramatically simplify a dictionary attack by
	forcing clients to use one chosen salt.
(7) Most existing kerberos realms have production practices that make most
	of the above moot.  This includes services that support or even
	require clear text passwords, services that don't check the integrity
	of the session, weaknesses in the human components that deliver
	initial passwords or handle password resets, &etc.  Web authentication
	is one area that is generally particularly hard to do "right".

In any real security system, there are interesting tradeoffs between
security and utility.  It's hard to do a really good job with either.
Even kerberos is not a panacea here.

When you say "md5", there are actually 2 things you could mean.
You could mean the MD5 hash algorithm, as described in RFC 1321,
or you could mean a common Unix "crypt" function replacement,
which I *think* was first done by Poul-Henning Kamp for freebsd,
which is based on md5 but includes an additional layer of nested
computational complexity on top of that.  The "computational complexity"
part is already obselete - computers are now fast enough that this is
not nearly as large a barrier to a dictionary attack.  The interesting
thing, though, is that md5 does in fact represent a reasonably large
active population of 128 bit keys with associated passwords stored in meatware.
It would be attractive to be able to leverage this installed base.
I have, in fact, been able to do just this on an experimental basis:
I've been able to take a Unix password file containing "md5" hashed
passwords, dump them into a kerberos database, and use those passwords
and keys with K5.  There's a ways to go from my experimental code to
actual practical production code--among other things, I ended up using RC6,
which lost in the AES competition.  There are efforts to define the use
of rijndael with K5, which seem to have gotten bogged down - too much of
what's been proposed seems to only exist in people's heads right now.
If this pans out right, though, it may well someday be practical to dump
a Unix shadow file with md5 hashed passwords into K5 and to use it with
AES.

					-Marcus Watts
					UM ITCS Umich Systems Group