[2850] in Kerberos
Re: Compromise of Master Key
daemon@ATHENA.MIT.EDU (Barry Jaspan)
Fri Oct 8 18:35:21 1993
Date: Fri, 8 Oct 93 18:24:22 EDT
From: "Barry Jaspan" <bjaspan@GZA.COM>
To: cdavies@remen.bell-atl.com
Cc: kerberos@MIT.EDU
In-Reply-To: [2848]
From: bbh7rqj@if000353.bell-atl.com (Davies)
Date: Fri, 8 Oct 93 16:49:27 EDT
I realize that if the master key is compromised and the database is
obtained that the security of the whole system is compromised.
Correct; an attacker that has master key and the database can print
any service ticket for any user.
I was wondering, however, exactly WHAT is compromised (i.e., user's
actual passwords obtained?, etc.) and exactly HOW it is
compromised.
A user's key is generated from its password with a one-way
string-to-key function. This key is then encrypted in the master key
and stored in the database. Therefore, if an attacker has both the
master key *and* the database, it can get the users key. This will
allow the attacker to act as the user in that realm, until the user
changes its password.
Having the user's key does not give the attacker the user's
*password*. The string-to-key function cannot be reversed to generate
the original password string. However, the attacker can perform a
dictionary attack on the key by running string-to-key over a
dictionary of likely passwords; if any of them produces the user's
key, then the attacker will have the user's password (or, in the
unlikely case of a hash collision, something as good as the user's
password).
The issue is slightly complicated by something called the "salt". In
Kerberos-speak, the salt is combined with the principal's name and
realm by string-to-key and affects the resulting key. Therefore, if a
principal uses the same password in two different realms, he will not
have the same *key* in the different realms, because the salt given to
string-to-key will be different. The practical upshot of all this is
that if an attacker steals the master key and the database of realm A
he will be able to act as users within realm A. However, even if a
user uses the same password in realm B, the attacker will not be able
to use the stolen key in realm B because the salt in realm B is
different.
In MIT Kerberos 4, no salt was ever used. In Transarc Kerberos (based
on V4), the salt is the realm name. In MIT Kerberos 5, the salt can
be the principal's name, the realm, both, or neither (the last for V4
compatibility).
Perhaps we can answer these questions under two different assumptions:
1) That the hacker HAS root
2) That he DOES NOT have root (perhaps poor permissions have
given away the master key).
This shouldn't be relevant. You should NEVER NEVER NEVER allow users
to log in to the Kerberos server, because Unix is known to be
insecure. Only admins should log into it, and then only on a directly
connected console. The Kerberos server should run on a dedicated
machine; it does not have to be a fast machine, so this isn't a big
expense. (A $1.5k 80386 PC running Linux will suffice, even for a
large realm.) Therefore, "poor permissions have given away the master
key" should never happen. An attacker cannot get root on the KDC
because he cannot log into the KDC at all.
Barry Jaspan, bjaspan@gza.com
OpenVision Technologies, Security Business Unit // Geer Zolot Associates
