On Monday 03 July 2006 16:19, Spruell, Darren-Perot wrote: > I mention > http://www.mindrot.org/passwdqc.html not because I know it can do what > you're looking for but because it can offer a few steps up in password > quality which may also be in your policy.
Yes, it does everything I need very nicely except preventing password reuse. > Seems to me a better solution would be to take a one-way hash of the new > password hash out to some kind of a database ... Very much agree. I think we're going to need something like this (similar to some of the file integrity monitors) soon. I'm doing a lot of preparation for security audits these days (mainly doctor's offices and credit card processors right now) and that's something the auditing firms want to see. Thanks for the assistance. On Monday 03 July 2006 16:19, Spruell, Darren-Perot wrote: > From: [EMAIL PROTECTED] > > > A client is setting up a password policy, and would like to > > prevent users from > > reusing a password for a period of time (four changes ninety > > days apart). Is > > there a way to do this, either within the OS or via a program > > in ports? I've > > been looking for quite a while and haven't found anything. > > I haven't either, although I haven't looked really hard. I mention > http://www.mindrot.org/passwdqc.html not because I know it can do what > you're looking for but because it can offer a few steps up in password > quality which may also be in your policy. > > I notice Linux's pam_cracklib > (http://www.deer-run.com/~hal/sysadmin/pam_cracklib.html) approaches this > by storing password hashes in a history file - meaning you have to > basically have the equivalent of your shadow file (with historically > valuable information) hanging around somewhere else. > > Seems to me a better solution would be to take a one-way hash of the new > password hash out to some kind of a database where a comparison could be > made against the last N password hash hashes that were used. Putting the > actual password hash out to storage for comparison seems more risky than > just a one-way hash of the hash (at least a little bit). A trigger on a > password change could easily tell if the new password hashes out to one on > record and records a hash of the hash if not. > > DS -- Jeff Simmons [EMAIL PROTECTED] Simmons Consulting - Network Engineering, Administration, Security "You guys, I don't hear any noise. Are you sure you're doing it right?" --My Life With The Thrill Kill Kult
