2

Upfront, I want to clarify that I am not a professional cryptographer, I am more curious about playing with the math and science behind it, and also want to improve my habits with my own personal and work data. I am not asking phishy questions to build a silly homebrew or anything like that.

I have been reading about the reasoning behind storing hashed passwords for a system's users and the requirements needed for that to fulfill the intent, namely, to slow the attacker down to acceptably low brute force speeds in the event of a breach. While there is a lot of info online, especially at this site, I have not seen this question answered yet.

I have had two acquaintances tell me something they experience at work. When their employers require password changes, they disallow similar passwords to the last few, let's say the last 5. Now, disallowing exact matches is fine, because systems like bcrypt detect exact matches (how else would passwords work?), but it seems to me that if the system can detect similar passwords, like password12 and password34, that suggests that they are stored in a recoverable way.

Is this not insecure? Does this not mean that an attacker who gets both the database and the scripts can figure out how to also recover passwords, or at least detect the "closeness" of his guesses?

Do any of you pros out there know of systems that do this in a way considered secure by the profession? Thanks.

  • Thanks, it looks like it is. The thread says that it is trivial for the last password, which is obvious. Maybe that is what is happening in this case. The people who told me about this are not computer scientists and might not think there is an important difference between the last one or last two. – Poisson Aerohead Apr 07 '15 at 00:08
  • @PoissonAerohead it's also possibly for the last X passwords - if (part of) the hash is saved - by bruteforcing (performing some basic transformation on the new password, hashing those, and comparing the hashes, see [this answer](http://security.stackexchange.com/a/4201/8754)), although [keeping a hash history](http://security.stackexchange.com/questions/85074) might not be a good idea. – tim Apr 07 '15 at 09:29

0 Answers0