60-second timeout in Unix login

[Thomas Truscott]

In article <260 at aiva.ed.ac.uk>, richard at aiva.ed.ac.uk (Richard Tobin) writes:
> ... The whole point of a good encryption algorithm is to make
> this sort of thing hard by making it slow.  (That didn't stop them
> using register variables in crypt(3), however.  ...)

A good encryption method must be more than slow, it must be
*inherently* slow, to reduce the payoff from brute force attacks.
crypt(3) achieves inherent slowness by iterating DES 20 times
(and by using a modified DES to thwart most chip implementations).

Non-inherent slowness is not a benefit, as the Bad Guy
can simply use a faster implementation for the brute force attack.
As it happens, crypt(3) is extremely inefficient.
Bob Baldwin (baldwin at mit-xx.arpa) has written a plug-compatible
equivalent that is sixty times faster.
Using it, our Gould 9050 can trial-encrypt all of /usr/dict/words
in *one minute* (for a given salt).
Slowing down *other* versions of crypt() does not change this!

For improved security one can use the fast version of crypt()
and iterate 1200 times so that it remains slow.

In summary:  An encryption method should be implemented as efficiently
as possible, yet still be slow.  Adding algorithmic inefficiencies
is no better (indeed is worse) than adding "sleep(1);"
	Tom Truscott