Subject: Re: crypt(3)
To: Tobias Weingartner <weingart@austin.BrandonU.CA>
From: David Maxwell <david@spinne.web.net>
List: current-users
Date: 11/17/1994 15:25:56
> 
> 
> Since reversing an MD5 hash is impossible (or 'sposed to be), and finding a
> message that hashes to the same is also equally hard, we do not have to slow
> down the algorithm at all.

Part of the reason for crypt being 'slow' (particularly the way it's used in
login) is to prevent brute force hacking. I could try your first name, last
name, pet's names....  On many sites this reveals an unnerving number of
unsecure accounts. (Run COPS on your site for more info :-)

One reason why DES crypt is less secure than it used to be is more powerful
machines, another is optimized DES crypt algorithms. It used to take about
1 second per crypt with old algorithms, new ones are 25c/s and up on the
same hardware.

> To make passwords even more secure, do something like on VMS, where you have
> a system dictionary.  When you change your password, it gets added to the system
> dictionary, and is not allowed for use within a certain time period again.
> This with a little bit of logic to check for pathological cases like changing
> only one or two characters will make hacking passwords very hard.

If someone is using 'mYx1tp1K' as a password, I really don't feel obligated to
stop them from using 'MyXlTplk' later. The Checks currently in use by many
Unixes (no loginid, at least one number, one Capital or punctuation mark)
should be sufficient. Keeping a dictionary won't matter if someone is
brute forcing every possible combination beacuse the algorithm runs fast.
  
> There is no need to slow the password algorithm down.  Why bog down the machine
> when you don't have to.  Make the cracking hard (next to impossible), and leave
> the speed alone.  If you really have to slow down something, put in a sleep(foo);
> wherever you want a pause.  In that way the machine can use that foo seconds
> for something more usefull.

Because you can take the fast formula and put it in a loop with
/* sleep (foo) */
and break anything you have access to the encrypted version of.
I agree that shadow passwording helps, but system holes can make that readable
too. As someone else here said, assume the shadow passwords are readable, if
not, you may as well store them as plaintext.

								David