Re: Current Best Practice regarding Password Change policy

["Harry E Flowers (flowers)" <flowers () MEMPHIS EDU>]

This reminds me of my VMS days... someone tried exactly that to get around the password history.  Trouble was, the VMS 
software engineers had thought of that and required selection of an auto-generated random password if you reached the 
history limit during the set history lifetime.  I had mercy on him and ended up bumping up the history limit on the 
system so he could set a new password without being forced to choose one of the generated ones. :)

It would be easy to implement this sort of thing for password changes on identity management web sites, too, without 
having to resort to minimum times between changes.  I think *not* allowing someone to change their password is a bad 
idea.  There are too many reasons someone might want to change their password again soon, such as logging in from a 
public computer that they worry might have had a key logger installed or they noticed someone looking over their 
shoulder.  Someone savvy enough to write a password-change script in an attempt defeat your password history security 
policy can appreciate having to use a randomized password for a while. :)
-- 
Harry Flowers

-----Original Message-----
From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Doty, 
Timothy T.
Sent: Friday, September 24, 2010 9:09 AM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] Current Best Practice regarding Password Change policy

Something I've always been curious about was the point of not allowing last
X passwords to be re-used. Won't the user simply cycle through passwords
(say, BadPassword1, BadPassword2, etc. or use a random password generator)
until the one they want is out of the history? I've personally known people
who have done this -- why wouldn't anyone who actually wanted to re-use a
password?

Tim Doty