[4848] in Kerberos
Re: Dueling Books
daemon@ATHENA.MIT.EDU (Jonathan I. Kamens)
Tue Mar 21 12:23:56 1995
To: kerberos@MIT.EDU
Date: 21 Mar 1995 17:14:20 GMT
From: jik@cam.ov.com (Jonathan I. Kamens)
In article <denbesten-2103951116210001@fubar.cs.bgsu.edu>, denbesten@cs.bgsu.edu (William C. DenBesten) writes:
|> I've been reading up on Kerberos with the idea of possibly implementing it
|> on my Sun workstations. In the process, I came across the following
|> passage:
|>
|> Unfortunately it [Kerberos] is plagued with holes ... passwords which
|> are stored in plain text on the authentication server.
|>
|> "Unix System Administraton Handbook, second edition"
Apparently, whoever wrote the text about Kerberos in this book either (a)
didn't do enough research to really understand how it works, or (b) has a
personal grudge against Kerberos and therefore decided to write misleading
things about it to make it look bad.
First, addressing the "plagued with holes" assertion in general -- it is true
that there are weaknesses in Kerberos 4. See the Bellovin paper, for example.
Some of those weaknesses are addressed in Kerberos 5, which has some
weaknesses of its own. However, Kerberos 4 and 5 both are certainly more
secure, by leaps and bounds, than generic UNIX security.
Now, about passwords. Entries in the Kerberos database on the authentication
server are encrypted in the server's master key. At paranoid sites, the
master password, which is used to generate the master key, is contained only
in the heads of one or more system administrators, and they must be present
when ever the KDC restarts (e.g., when the machine it's on reboots), to type
the password into the KDC in order for it to be able to restart. The master
key is then stored by the KDC in its memory and used to decrypt database
entries as they are needed.
At less paranoid sites, the master key is "stashed" in a file on the server
machine, and the KDC reads that file when it starts up.
If an attacker gets your Kerberos database's master key, *and* he has access
to the data in the Kerberos database, then he can determine the key of any
user or service and therefore can impersonate or interfere with the
authentication of users and services. In other words, at a very basic level,
if someone can break into your authentication server machine and get his hands
on the master key either because (a) it's stashed or (b) the attacker has
broken root and therefore can read the address space of the KDC process, then
yes, the attacker has access to all user keys, which are functionally
equivalent to passwords. On the other hand, using those compromised keys is
not an incredibly easy task, because a user's password can't be derived from
his key, which means that the attacker has to do something significantly more
sophisticated than typing a username and password at a login: prompt in order
to take advantage of the stolen data.
All of this is why the authentication server is supposed to be kept secure,
with as few services running on it as possible, and with as few people allowed
to log into it as possible, and preferably with those people only allowed to
log into it over the network using Kerberos-authenticated connections.
It is incredibly misleading to state that the passwords are stored "in plain
text" on the Kerberos server. That implies that it's easy for an attacker who
has broken into the Kerberos server to steal data that will allow him to
impersonate users, and that isn't the case, because it takes quite a bit of
work to be able to do useful villainy with a stolen KDC database. It also
implies that an attacker can get user passwords from the Kerberos server,
which isn't true either -- user passwords can be turned into keys, but not
vice versa.
All the quote above is really saying is that Kerberos is a secret-key
authentication system, and secret-key authentication systems require a secure
repository which knows all keys. That may be a weakness of Kerberos, but it's
a known, out-in-the-open weakness which is hardly grounds for calling Kerberos
"plagued with holes".
|> This is a book that I generally trust, but I can not believe that Kerberos
|> would keep clear text passwords around. Further reading yields:
|>
|> Actually, the initial ticket that the Kerberos Server sends your
|> workstation is encrypted with a 56-bit number that is derived from
|> your password using a one-way cryptographic function. Kerberos uses
|> encrypted passwords for the encryption ... [to reduce] the damage that
|> would occur if the Kerberos master password file were somehow stolen
|> by an attacker.
|> "Pratical Unix Security"
|>
|> This quote sems like a much more reasonable approach to me. Please tell
|> me that the first book is incorrect, or at least that it is discussing a
|> significantly older version of Kerberos.
|>
|> The second quote implies that the passwords are stored on the server using
|> crypt().
No. A Kerberos-specific one-way string-to-key function, based on DES but not
at all equivalent to crypt(), is used to turn passwords into keys. Those keys
are then stored in the Kerberos database, encrypted in the Kerberos master
password. Kerberos doesn't use crypt().
The end of the paragraph above is referring to a scenario in which an attacker
managers to steal the Kerberos database but not the master key. Without the
master key, the Kerberos database is pretty much useless to an attacker.
|> If so, does there exist a program which would convert from
|> /etc/password to a kerberos password database. If it does not exist, is
|> this a program which is technically feasable to write?
No. No.
--
Jonathan Kamens | OpenVision Technologies, Inc. | jik@cam.ov.com
