Yes this is exactly what I had expected. Thanks. I was primarily asking if it was possible that this is fine, snd you have answered this exactly: that it isn’t secure.

Some higher up misunderstood what security is, tried to make it more secure, and ultimately made it much worse. It'll also be like this if anyone tries to "improve" their security through technical means. Best to use public and widely tested packages that has a good record of serious fixing bugs.

@schroeder and Ja, see my edit: I was shocked to find out about the real reasoning and how misleading the rejected password message is. When a password isn't acceptable for this reason, the exact quote is: Your password is too similar to another co-workers password. This voids our security policy, so please choose a new one.

I never would have assumed, from this message, that the rejected password is too similar to my co-worker's old password. Is this secure?

@security_paranoid: No, this is not secure, because the old password of a co-worker may reveal information about the current one. Of course this is not quite as bad as comparing current passwords, but it's insecure regardless. What the passwords of co-workers look(ed) like is nobody's business. Only similarity checks within a user account may be acceptable (to prevent people from reusing passwords or only making minor modifications). And of course the real solution is to either get rid of password-based authentication altogether, or to at least teach people to use random passwords.

@Ja1024, but like I said, the policy also prohibits employees from changing their new password to something too similar to their old/current one, meaning that it shouldn't matter if I can somewhat roughly guess what my co-worker's old password is. Unless you mean something other than direct security, like privacy, when you say it is nobody's business? "Of course the real solution is to either get rid of password-based authentication altogether"- I completely agree agree, I think we would much better benefit from maybe either Biometrics or even better OTPs.

@security_paranoid: The system can only detect specific similarities, so the new password of a co-worker may still follow the same pattern or have the same meaning. For example, to pass the check, a co-worker might replace a few characters with similar-looking numbers (e.g., some leetspeak variant). Those replacements are trivial to test for an attacker, so exposing the old password would be a major mistake. Annoying password policies might actually backfire and teach employees to pass the check with minimal effort instead of actually coming up with secure passwords.

@security_paranoid: I’ve seen a lot of biometric authentication methods get bypassed, so I’m sceptical this is a good approach. I was thinking more of: smartcards, hardware tokens in USB format, or (software) passkeys. If passwords are the only option, then I’d at least introduce another factor and encourage people to generate purely random passwords with a password manager.

@Ja1024 yeah I hadn't though of a password manager but that's probably the best bet. And you're right about the fact that the policy probably can't detect passwords that are actually similar. Such as the old password backwards!

"A similarity check requires the password to be stored in a recoverable form" ─ not necessarily, you can produce variations of the new password and then verify it against the stored hashes. More or less expensive depending on how many variations you want to try; if the rule is "no matching of 5+ characters" then you only have to try a few thousand variations of an 8-character password. "Even an exact comparison is impractical" ─ highly speculative. Yes, password hashing algorithms are tuned to take more than milliseconds, but you can still try a password against a few thousand old hashes.

@kaya3 Facebook does (or did; idk if they still do) something very similar to what you suggest. security.stackexchange.com/q/53481/80012

@kaya3: Nonsense. First off, modern password hashing algorithms are configurable and take however long you want them to take -- this can be 1 second or more. So “a few thousand” comparisons can add up to several hours. That's obviously unacceptable. Of course you can also massively reduce the strength to make the comparisons worthwhile, but then you also facilitate brute-force attacks. Remember that hash calculations are supposed to take long. Secondly, the OP has already described how the comparisons are actually implemented, so your speculations are irrelevant (and nothing new).

@RichardWard: (1) This is from 10(!) years ago. (2) The OP already said how the comparisons are implemented (by encrypting old passwords). I don't really care how they could have been implemented. And this has already been addressed by many other users (like gnasher729).

@Ja1024 A few hours of computing time to detect and correct a weak password is not "obviously unacceptable" - in many contexts it is obviously acceptable. Back before slow hashes weren't in use, some IT departments would constantly be brute-forcing their own users' passwords on a spare machine, so that if any were broken they could ask the users to choose stronger passwords. There is also no need to emphasise to me that modern password hashing algorithms are intentionally slow when I already said this in the comment you are replying to.

Anyway, the first sentence of your answer, "A similarity check requires the password to be stored in a recoverable form", is demonstrably wrong, as I explained. It doesn't matter whether the particular implementation the OP described in a comment does store passwords in a recoverable form; you made a universal statement.

@kaya3: The OP has already explained how the comparison is actually implemented: by encrypting the old passwords. I don't care how it could have been done when you're willing to spend hours of computing time or how it was done back in the days or how Facebook did it 10 years ago. I'm interested in facts, not speculations. If you want to do a brainstorming session on how a similarity check could be implemented, this is the wrong question, possibly even the wrong site.

I'm not speculating about the question, I am pointing out a counterexample to a claim you made in your answer.