4

Closely related (but not a duplicate): Company can tell if new and old passwords are too similar. Is there a security problem?

Also closely related (but not a duplicate): How can a system enforce a minimum number of changed characters in passwords, without storing or processing old passwords in cleartext?

A particular company (I won't say which one) requires that my password not be similar to any of the previous 5 passwords.

According to the linked questions, when they check to see if your password is too similar to the previous one, they just force you to enter both the old and new password and compare them that way. I understand that, and there doesn't appear to be any security problem with that.

However, the company in question actually compares my password to the previous 5 passwords, none of which I enter. How might they be doing this? Should I take this as evidence that they're either storing my passwords in plaintext or that they're using a really weak hashing function, or is there a legitimate way that they could do that without potentially compromising my password?

The linked answer in the second linked question briefly alludes to this issue but doesn't really fully address how they might be doing this or how big of a security concern it is.

  • 1
    Maybe this one answers your question? – AndrolGenhald May 23 at 19:41
  • @AndrolGenhald That one's actually really helpful - for whatever reason I didn't find that one when I searched. – EJoshuaS May 23 at 19:48
  • "weak hashing" would not work. Either they store the old passwords in the clear or in reversible encryption, but in any case not in a recommended way to store passwords. – Z.T. May 24 at 16:04
  • Can you provide some examples of what they consider too "similar"? Or is that just language they use in their policy and you haven't observed rejections? – PwdRsch May 25 at 17:36
3

Could be done in a variety of ways:

  1. Keep a list of the last five passwords used, hopefully encrypted. Not the safest thing obviously, but certainly do-able.
  2. Keep a list of hashes related to the last five passwords, e.g. full password, first X characters, last Y characters
  3. Keep a list of characteristic patterns of the last five passwords, e.g. llllllllds. l being letter, d being digit, s being a special character. If the pattern is the same, but the hash different, then it's just too close.
  • Would #3 be a form of security by obscurity? – EJoshuaS May 23 at 17:17
  • 1
    No, but it's a potential security hole as an attacker that could obtain that information could brute force the password with a very narrow set of constraints (relative to having no information about the password other than it must meet the site's requirements). – Swashbuckler May 24 at 15:12
  • Also possible: store the last 5 password hashes. Generate a bunch of variants of the new password and hash them. See if they match. – Ben May 24 at 15:53
  • @Ben That's possible. Wouldn't that make the system more vulnerable to some variant of a known-plaintext attack, though (because you could then study the differences between the hashes)? – EJoshuaS May 24 at 16:03
  • 1
    No currently used cryptographic hashes are vulnerable to known plaintext. – Ben May 24 at 16:05
2

They could store a clear text or encrypted version of your old passwords once they're changed. You said that you'd have to give your previous password, which is clearly available at the time of change. Once changed , it could be stored in a way that allows comparison.

There's a possibility that it's done "right" for certain values of "right". E.g. If you reuse any of those passwords on other sites, that'd still not be good.

  • Yeah, that's a possible implementation. I'm hoping that that's not what they're doing, but maybe they are. – EJoshuaS May 24 at 16:00
1

They can do that even if all they have is proper strong hashes from the previous passwords, as long as their idea of “similar” is sufficiently narrow. Take the new password and enumerate all the passwords they consider similar. For each variation, calculate the hash with the salt for each previous password. If there are P previous passwords and N similar passwords, the cost is P × N hash calculations. Those calculations may be performed in parallel if they have enough hardware, so you can't tell how many hash calculations they perform from the time it takes to do the verification.

5 × N gets large pretty quickly. Just trying all one-letter variations on an 8-letter case-insensitive password would be 1000 calculations, for example. But with heuristics such as only varying digits (e.g. swordfish5swordfish4) or removing repeated letters (e.g. swordfishhswordfish), the number could stay manageable.

A mild way in which they can cheat is to always use the same salt for a given account. Then the cost of trying variations is independent of the number of previous passwords. Reusing the same salt after a password change on the same account immediately reveals if two passwords are the same, but other than that it doesn't make attacks easier.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.