[logfromblammo]

If that policy is enforceable, someone would have to be storing passwords in plaintext, or the hashing algorithm is too weak.

IT shouldn't be able to tell anything about plaintext password similarity beyond equals or not-equals.

[Sohcahtoa82]

Ad-hoc, this is correct.

But at the time of the password change, no, assuming password changing requires you to enter your current password as well.

[Vendan]

If just with previous password, then yeah, that's fine, but more then likely they are saying with the previous N passwords, which would require storing the previous N passwords in some kind of plain text or easily reversible form. Even if those old passwords are useless at that point (which might not be the case for something like a laptop that hasn't talked to the domain controller and learned that the password has been updated or something), it's still dangerous (what if they used that password on a vendor's site, or on their own banking login...)

[logfromblammo]

The password-change form should be using a password field, and that should not be allowing any code or scripts to grab the plaintext stored in it.

If the code that compares your current password to the new password can read the plaintext of your passwords, so too could a malicious program.

Using HTML input type="password" alone is not sufficient protection. The same steps that protect password changes from malicious attackers must necessarily protect them enforcement of bad IT security policy.

[Arrath]

I had a similar concern. Or maybe it was a company wide email and that language was in there just because.

Of course, our company-wide email was down for 2-3 months a couple years ago due to a ransomware infection, so our IT isn't stellar. So who knows!