Newsgroups: comp.risks
X-issue: 14.35
Date: Wed, 10 Feb 93 18:19:20 -0500
From: "Jonathan I. Kamens" <jik@aktis.com>
Subject: MIT's on-line Student Information Services (SIS) 

(Re: "Anyone can get your U. of Illinois transcript" in RISKS-14.31)

MIT recently put on-line a new service, SIS, through which students can access
data in the registrar's database, including both personal and confidential
data about their own status and general data such as course schedules.

SIS is worth mentioning here, in response to Carl Kadie's message about
problems with a similar system at the University of Illinois, because (in my
opinion) SIS is a good example of system designers taking security issues
seriously enough and doing a good job of meeting security needs.

In order to use SIS to access personal data, a user must first register an
"extra" password with the Kerberos database.  The program that registers this
password does so by transmitting it to the Kerberos server in encrypted form
(using a key derived from the user's main Kerberos principal, for which he
already has a password) so that it isn't exposed to the network.

The assumption that led to the extra-password requirement is that people
already have the mindset that it's OK to share their accounts (i.e., their
main Kerberos principal password) with other people, so that name/password
pair is not sufficient authentication.  The documentation about SIS, and the
prompting that takes place when the user chooses an extra password, makes it
very clear that this password should be treated more securely by the user, and
that if the user sees fit to give it to others, that user is giving those
others access to his personal data in the registrar's database.

Once the user has registered for an extra password, he still can't access
personal data in the registrar's database immediately.  A notification is
mailed, by U.S. Mail, to the address for the user in the registrar's database.
About a week after that notification is received by the user, the password
actually becomes active and the user can access personal data on-line.

Obviously, this second safeguard is to protect against the possibility of a
user registering another user's extra password.  The notification mailed to
the user explains in detail what it's about, and tells the user whom to
contact if he *did not* register an extra password.

I suspect that an extra password does not become valid if the paper mail
notification is returned by the post office (i.e., is not successfully
delivered to the user).  Granted, the time given for the notification to be
returned by the post office probably isn't sufficient for all failed delivers,
but I think that the probability of a notification not being delivered
properly to someone whose extra password was illicitly registered by someone
else is sufficiently low that this is not a concern.

Once a user's extra password becomes valid he must type this password each
time he wants to use the SIS service to access personal data (and he must
already have valid Kerberos tickets for his main principal).  The Kerberos
tickets thus acquired are used to establish a Kerberos-authenticated network
connection to the machine on which the registrar's database resides.
Furthermore, the session key created while establishing that connection is
used to encrypt all personal data sent over the network.

There is one more safeguard to prevent security breaches of the database.  The
SIS protocol does not allow for direct modification of the database on the SIS
server.  Most data in the system can't be modified through it at all; instead,
users must talk to the registrar directly to effect changes.  The data that
*can* be modified is mostly MIT directory information, e.g., term address and
phone numbers, and when a user requests modifications to that data, the
modifications are stored and manually eyeballed for sanity by the registrar
before actually being fed into the system.

Finally, just in case there is some possibility that someone might manage to
break into the database machine (although it's pretty fortress-like in its
configuration :-), that machine is not actually the "home location" of the
registrar's database.  It's a copy that is updated by SneakerNet (a tape
carried from the registrar's office) regularly.  The registrar's computer is
on a subnet that is isolated from most of the campus network (and that is
certainly more paranoid about who gets to connect to it than the rest of the
campus network).

As you can see, I think that the people who designed and implemented
SIS did a good job of meeting security concerns.  Their only mistake
was using Motif for the UI :-).

Jonathan Kamens              Aktis, Inc.                 jik@Aktis.COM

Newsgroups: comp.risks
X-issue: 14.36
Date: Wed, 24 Feb 93 18:14:16 -0500
From: "Jonathan I. Kamens" <jik@aktis.com>
Subject: Kerberos and password-guessing attacks
	(was MIT's on-line Student Information Services (SIS))

   From: smb@research.att.com
   Date: Wed, 24 Feb 93 12:21:43 EST

   But has the Kerberos protocol been beefed up yet to guard against
   password-guessing attacks?

Yes.

The most recent release of MIT Kerberos Version 4 includes kadmin
protocol enhancements to allow for the rejection of weak passwords,
and code on the server to check and reject weak passwords.

I don't know if any V4 vendors have incorporated changes like this
into their products; I suspect it will happen eventually if there is
enough demand for it.

Furthermore, MIT Kerberos Version 5 supports optional preauthentication.  MD5
on the user's password, Smart Card technology, or some other technique (the
code is pretty abstract, so new preauthentication types can be added
relatively easily) is used to create a "magic cookie" which is passed to the
server along with the TGT request.  If the cookie is wrong, the server won't
give the user a TGT to decrypt.  Preauthentication can be required or optional
on a principal-by-principal basis.

MIT V5 doesn't yet have weak-password rejection in it, but the hooks for it
are there, and it will be added before the first official (i.e., not beta
test) V5 release.

I don't think DCE Kerberos has preauthentication in it right now, and I don't
think they plan to add it before the first official DCE release (If you want
them to, and you're a member of the OSF, then let them know!).  I don't know
whether or not DCE Kerberos has weak-password rejection in it.

It is true that both V4 and V5 are still vulnerable to network eavesdropping
weak-password attacks, since an eavesdropper can watch for a TGT on the
network and try to decrypt it once it arrives, even if he doesn't know the
preauthentication magic cookie which convinced the server to send the TGT.
However, weak-password rejection makes the risk of an attack of this sort
minimal, and it is not vulnerable on an entire-Internet scale like the attack
which Steve mentioned.

(Thanks to Ted T'so, tytso@mit.edu, for confirmation of much of the
information above about V5.)

Jonathan Kamens                                       jik@Aktis.COM