[1034] in Kerberos
User-chosen passwords
daemon@ATHENA.MIT.EDU (Michael Merritt)
Tue Jun 19 15:33:36 1990
Date: Mon, 18 Jun 90 17:18:03 EDT
From: mischu@allegra.tempo.nj.att.com (Michael Merritt)
To: kerberos@ATHENA.MIT.EDU
Here's our thoughts on the great dictionary-attack
debate:
It is an historical truth that people like to pick
their own passwords, that they are bad at it, and
that many system administrators are not in the position
to enforce standards.
Furthermore, it is empirically true that bad passwords
are used heavily by attackers, as amply documented by Stoll,
Reid, and others.
For a system with the high appeal and utility of Kerberos,
a reasonable effort to protect against dictionary attacks
is in order. We endorse the following two suggestions, made already
in this space, as reasonable trade-offs that substantively
increase security against this attack.
Suggestion 1:
First, clients should be distinguished from servers
so that tickets will not be granted for clients.
(Or at least not for clients who pick their own passwords.)
Rationale:
The "clean abstraction" of equating clients and servers
seems more confusing than otherwise, and certainly not
worth sacrificing security for. One bit in the
database is a small price to pay.
Note that for user passwords, any valid use of such a ticket
would require that the user re-enter the login password,
which is contrary to a major goal of Kerberos. Why support
a feature that can't be used cleanly for legitimate purposes,
and opens up security holes?
Suggestion 2:
The initial ticket request should demonstrate that
the requestor knows the password, e.g. by encrypting
the request with the password.
Rationale:
This means holding the password at the client's machine
for one round-trip delay. At the cost of increasing the
duration that the password is vulnerable at the client end,
another entire modality of attack is eliminated.
(I.e., instead of requesting a password-dependent
message as a specifically-supported capability, such
messages can only be obtained by eavesdropping.)
Compared to the time between keystrokes,
this delay may be negligible anyway.
(The characters of the password sit SOMEWHERE until
you hit return.)
Steve Bellovin
Michael Merritt
AT&T Bell Laboratories
