How can a system enforce a minimum number of changed characters in passwords, without storing or processing old passwords in cleartext?

Question

In some environments, it is required that users change a certain number of characters every time they create a new password. This is of course to prevent passwords from being easily-guessable, especially with knowledge of old passwords such as a departed employee might have for a shared service account.

I have separate questions open to address button-pushing side of this enforcement. However, I'm also curious as to how this enforcement works on the back end. If a cleartext password cannot be derived from a strong hashing algorithm, how does the system determine how many characters have been changed in new passwords?

Answer 1

I'm not sure about comparing with all the passwords the user has previously used, as it really depends on the hashing system your using and I would say if its possible to derive any similarity from the hash then its not a very good system to begin with.

But assuming that the user has to supply their current password when setting their new password, you could at least check the new one against the current one as you'll have both as unhashed at that point.

The pam_cracklib module on Linux checks passwords like this and does a few basic checks by default.

• Is the new password just the old password with the letters reversed ("password" vs. "drowssap") or rotated ("password" vs. "asswordp")?
• Does the new password only differ from the old one due to change of case ("password" vs. "Password")?
• Are at least some minimum number of characters in the new password not present in the old password? This is where the "difok" parameter comes into play.

You can find some more details about it here.

Answer 2

This is easily done on password change (where the user is and should be asked to provide both old and new password).

Answer 3

The user should enter both old and new password for a password change. So comparing the new password to the old one can easily be done because the plaintext version is given by the user.

For comparing the new password against previous passwords (other than the current one), checking can only be done by comparing the hash-results. Any method that would allow any other comparison would be a security hole.

Answer 4

It can be done only by keeping hashes, it could even be done over several iterations.

The method would be to take the password and iterate it through the hashing algo and check for comparisons against the stored values.

For instance, most users (and service desk folks love to fallback on this as a last resort with angry-important types) will iterate their passwords incredibly simply.

So taking the password: #foob@r1 and making it #foob@r2 which you're likely to see can be tested without knowledge of #foob@r1 by performing a brute force on the algo quickly. With modern processing power you could iterate through the first 4 characters in less than ten seconds.

Though for efficiency sake the last four are typically the ones people change so you're likely to see bigger bang for your buck there. If you're going to do non-consecutive and consecutive you're looking at a pretty big wait for the end user and a big chunk of processor.