On Mon, Jul 03, 2006 at 09:22:59PM -0700, Jeff Simmons wrote:
> Well, just to play the devil's advocate here ...
>
> One of the main functions of any password hygiene program 'should' be to
> prevent users from changing 'mypassword1' to 'mypassword2' and then
> 'mypassword3', etc. (Yes, we can force complex passwords, but the idea is
> the same.)
>
> It's fairly simple to compare 'newpassword' to 'existingpassword' and prevent
> this sort of behavior (I THINK that's what the -s option to passwdqc is for,
> but the man page is kind of ambiguous and I haven't had time to dive into the
> source yet - pam_passwdqc does it) but then the user can just do
> 'mypassword1', 'mydogsname1', 'mypassword2', mydogsname2', etc. and totally
> invalidate your carefully designed security policy.
>
> And hashes aren't gonna help.
>
> Don't get me wrong, I'm not knocking the idea completely. My assignment here
> is that I've been told that in order to get my client certified I have to
> avoid reuse of a password over a cycle of 4 90 day forced changes. My JOB is
> to assure that doing this doesn't open my client up to a whole new string of
> vulnerabilities. Mr. Rock, meet Mr. Hard Place.
>
> "In conclusion the main thing we did wrong ... was to worry about criminals
> being clever; we should rather have worried about our customers ... being
> stupid." Ross Anderson, "Security Engineering"
This suggests a rather fascist, and thus very effective approach: deny
the users the right to create their own passwords, but institute some
scheme that produces strong, but hopefully memorizable passwords.
Of course, whether or not dd if=/dev/urandom bs=8 count=1 | b64encode -
can be considered to produce memorizable passwords is open for debate,
but the passwords it produces are quite strong, and can be typed from
any reasonably modern box (say, anything that's not an all-caps text
terminal - note that /usr/bin/login supports those, and this support is,
in fact, documented in the FAQ).
In fact, the above is exactly the way I generate at least part of my
passwords. It's not necessarily possible to get everyone else to do it
this way, though.
However, do note that unleashing a fuzzer of some sort on the entered
password and comparing the hash of each iteration to a list of
previously-used hashes, while computationally intensive, is both
moderately secure and reasonably easy to implement.
Another thing worth considering is what happens when a user changes the
password four times in five minutes. Or, more dangerously, what happens
when a user keeps submitting twenty password change requests per second.
Joachim
