[cryptography] Password non-similarity?

Solar Designer solar at openwall.com
Tue Dec 27 17:48:23 EST 2011

On Tue, Dec 27, 2011 at 03:54:35PM -0500, Jeffrey Walton wrote:
> We're bouncing around ways to enforce non-similarity in passwords over
> time: password1 is too similar too password2 (and similar to
> password3, etc).
> I'm not sure its possible with one way functions and block cipher residues.
> Has anyone ever implemented a system to enforce non-similarity business rules?

In passwdqc, we opted to only do it for the current vs. previous
password, not maintaining a password history.  (The previous password is
normally entered by the user at password change time.)

Password histories are controversial.  They do not obviously improve
security; they may as well make things a lot worse (even if you're just
storing hashes).

Also, you shouldn't declare two passwords too similar just because they
contain e.g. an N-character substring in common; rather, you should see
if the remainder of the new password (with the too-similar portion
removed or partially discounted) would still meet the policy.  This is
what passwdqc does.

KoreLogic ran a password hash cracking contest at DEFCON 2010 (with many
remote participants as well) focused on effects of password histories -
that is, they tried to simulate users' behavior patterns that they
observed in corporate environments with password histories.  After the
contest, they released John the Ripper rules that try to match users'
typical approaches at bypassing password histories - appending the
current year, month name, etc.  Apparently, this is what actually
happens when there's a password history and regular password changes are

The DEFCON 2010 contest (including related data files):

passwdqc tested on the contest passwords:


More information about the cryptography mailing list