[574] in Kerberos
password checking
daemon@TELECOM.MIT.EDU (Mark Lillibridge)
Sun Jan 8 21:20:58 1989
From: Mark Lillibridge <chariot@ATHENA.MIT.EDU>
To: Saltzer@ATHENA.MIT.EDU
Cc: jis@ATHENA.MIT.EDU, kit@ATHENA.MIT.EDU, mar@ATHENA.MIT.EDU,
In-Reply-To: Jerome H. Saltzer's message of Sun, 8 Jan 89 01:00:51 EST <8901080600.AA09155@HERACLES.MIT.EDU>
Reply-To: chariot@ATHENA.MIT.EDU
There has been a flame war going on in various net-news groups
on password security for the last week or so of upwards of 200 messages.
I will summarize what I feel to be the general consenus:
1) If possible, always implement shadow password files. They
combined with reasonable logging and the slowing down of password
retries prevent attackers from trying more than a few passwords on any
given account. However, should the shadow file be obtained (say, though
backup tapes or a read anything security bug), security is the same as
if no shadow file had existed. Hence, shadow files help increase
security but by themselves are insufficient.
2) Due to better DES implementations, use of multiple machines,
ever increasing processer speeds, and the like, only the use of a large
key space offers any real hope of increasing security. There are only
two real ways to get a reasonably large key space:
a) Generate randomly generated passwords like
"%2hWE}dI". The users are to write them down on a piece of paper and
keep the paper in their wallet. The piece of paper should then be
treated like a key or credit card. Of course, should they lose the
paper, they should implemently change their password.
b) require all passwords to be a MINIMUM of 28
characters long. Each character is then used to provide 2 bits of
information for the key. (note: english text has about 2 bits of
entropy per character, hence the choice of 28 letters. If you are
interested on how entropy relates to this, ask me) Each user then
chooses an uncommon english phrase of at least 28 characters to remember
as his password. Example "a hen lays 13 eggs once in a blue moon".
Note that it is easy to think of unguessable but easy to remember
passwords of this form. Note that every possible DES key can be
generated with close to equal frequency with a scheme of this variaty.
Note that the list of limitations Jerry mentioned (1 punucation
character, both upper and lower case used, etc.) only begins to approach
a reasonable key space if a LOT of rules are used. Unfortunely, at this
point, it becomes VERY hard to think up easy to remember passwords
causing the scheme to backfire.
3) Password ageing does not seem to be too important except at
very high levels of security. The consenus on this is not as strong as
on the other 2 points.
As far as Athena goes, shadow files can not be added to
Kerberos. (The attacker can merely steal a pervious login session and
keep trying guesses as long as he wants without talking to kerberos.
Even zero-knowledge proofs will not help here.) Hence, it is all the
more critial that at least one of the 2 options of #2 be adopted. Since
either of these two methods would require a user visible change, perhaps
we may want to make the new security optional (with the understanding
that anyone with a root password should be using it...)
One thing that needs to be done is to make the normal unix
password routine and the kerberos one use exactly the same input and
encryption routines. This is an issue because kerberos and the normal
unix password routines do different things on passwords longer than 8
characters.
I hope this leaves you with something to chew on,
- Mark
