password quality script aka --with-cracklib replacement

John H Terpstra jht at
Fri Feb 14 01:49:41 GMT 2003

On Thu, 13 Feb 2003, John E. Malmberg wrote:

> Richard Sharpe wrote:
> > On Fri, 14 Feb 2003, Andrew Bartlett wrote:
> >
> >>Anybody doing this 'must change password every x days' thing has to
> >>store the decrypted password, or else your users change from password1
> >>to password2 to password3 then back to password1.
> >
> > Hmmm, I am not sure of that. What is wrong with storing the history of
> > password hashes back to some number. Sure, there can be collisions, but
> > they should be infrequent, and it will prevent them from re-using the same
> > passwd within the horizon of the hashes kept.
> OpenVMS stores the password hashes back a configurable amount of time,
> the default is one year per user.

On MS Windows NT/2K you can set a number of password change policies.
There are add-on packages that extend this. The password change scheme I
have seen most used is time based, with storage of the last 'n' number of
changes having to be unique. 'n' is usually 6-12. At one large site I
consulted to in 1996 'n' was 4, the result was that on a security audit I
found that users had a list of their 4 passwords in change order on yellow
post-it notes on their monitors. Great security!

> The storage time needs to be timed based, not number of changes.

Usually, minimum time till change is again permitted as well as ultimate
password expiry if not changed time 'usually dat or # days based.

> OpenVMS does not have the security hole where a user is forbidden to
> change a password for a period of time from the last change, so that a
> user must notify the system administrator when they think a recently
> changed password was compromised.
> Frequent password changes also lead to passwords that are more easily
> cracked by social engineering methods.  Usually if you have learned a
> past password, a human can figure out all future passwords.

>From my site auditing work I could not agree with this generalization. It
might be the case with < 10% of the people I had exposure to. But then
this would be moderated if the site has a documented password security
and change policy.

John T.
John H Terpstra
Email: jht at

More information about the samba-technical mailing list