Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!pasteur!agate!eris!chapman
From: chapman@eris (Brent Chapman)
Newsgroups: comp.unix.wizards
Subject: Re: Remembering old passwords (was 60-second timeout in Unix login)
Message-ID: <7075@agate.BERKELEY.EDU>
Date: 20 Feb 88 07:47:21 GMT
References: <10578@brl-adm.ARPA> <721X@jimi.cs.unlv.edu> <465@xios.XIOS.UUCP> <18083@topaz.rutgers.edu> <2178@ttrdc.UUCP> <18174@topaz.rutgers.edu>
Sender: usenet@agate.BERKELEY.EDU
Reply-To: chapman@eris.UUCP (Brent Chapman)
Organization: UNIXversity of California at Berkeley
Lines: 35

In article <18174@topaz.rutgers.edu> ron@topaz.rutgers.edu (Ron Natalie) writes:
>Remembering old passwords doesn't involve storing the passwords in the
>clear anymore than remembering the current one does.
>
>Jeez.

Ya, but you'd need to check the current password with _all_ the salts used in
the past passwords.  Assume you have 50 users who change their passwords
monthly.  After a year, you've got (potentially) 600 different salts to
encrypt the new password with and compare to the old passwords. 

Now, if I remember the results of the tests I ran several months ago
correctly, my unloaded Sun 3/280 (not exactly a wimpy machine) can
encrypt about 20 passwords a second.  That's 30 seconds to check 600
salts.  Assume that, on average, if a password is being "reused", it
will be discovered half-way through the check.  The user _still_ has to
wait 15 seconds to be told "sorry, try another password".  And _that's_
assuming you have a relatively fast, unloaded machine; I'd hate to think
what it would take on a VAX 11/750 with an average daytime load of 2.0, for
instance.

The more users you have, and the more they change their passwords, the longer
the delay gets.  What you end up providing is a strong incentive for users
to _not_ change their passwords, because it's such a pain in the ass. 

Effective security needs to be as "transparent" and easy to Joe User as
possible, otherwise Joe User will do something to make his life easier,
but that has the side effect of blowing your so-called "security" all to hell.


-Brent
--
Brent Chapman					Capital Market Technology, Inc.
Senior Programmer/Analyst			1995 University Ave., Suite 390
{lll-tis,ucbvax!cogsci}!capmkt!brent		Berkeley, CA  94704
capmkt!brent@{lll-tis.arpa,cogsci.berkeley.edu} Phone: 415/540-6400