22

  • I've spoken to an employee of a big international company in germany.

  • He said, employees are warned if their new password is too similar to the old password. (e.g. if they change the password from ThePassword12345 to ThePassword12344.

  • The aim of using hashing functions is to not be able to tell the difference between a password and a random string.

  • As they can tell if the difference is too small, they have to save at least one password in cleartext.

  • The employee said they use Windows/SAP systems (and the warning occours on all systems)

My Question is therefore if my analysis is correct or where my error is. As they hire also lots of computer science people, i would guess the error relies on my side, not theirs.

Community
  • 1
toogley
  • 385
  • 2
  • 12
  • 18
    When the users change their password, do they need to input their old password too? – pri Oct 14 '16 at 05:51
  • 8
    Check this answer. http://security.stackexchange.com/questions/3170/how-can-a-system-enforce-a-minimum-number-of-changed-characters-in-passwords-wi – one Oct 14 '16 at 05:54
  • 4
    Related: http://security.stackexchange.com/questions/53481/does-facebook-store-plain-text-passwords?noredirect=1&lq=1 – toogley Oct 14 '16 at 08:12
  • @PriyankGupta yes. – toogley Oct 14 '16 at 13:12

2 Answers2

38

Usually, when users change their password on a system, they're required to input their old password as well, along with the new password.

Now, this old password is hashed and checked against the hash stored in the machine(password is not stored in cleartext). If the hashes match, then the system proceeds to compare the old password and new password. If it finds that the 2 passwords are too similar, then it throws an error, informing the user about the same.

In case the passwords are sufficiently different according to the system logic, then the new password is hashed and this new hash value is stored in the system, hence successfully changing the user's password.

In case the users are NOT required to input their old password, I'd recommend you better check with your IT support team, and raise a concern with the system owner...

UPDATE: As pointed out in the comments, there's one more way to get around this issue without asking for user's old password. When the user enters the new password, the system generates the variations of the new password entered, hashes each one of them, and compares each hash against the old password's hash. If any of the hash matches, it throws an error. Else, it successfully changes the password.

pri
  • 4,438
  • 24
  • 31
  • 9
    Without requesting the old password it is still possible to do: you just hash multiple slight variants of the password just for this purpose. Sure that's a bad idea for other reasons, but still better than storing the password encrypted/in plaintext. Also in this case avoiding the check should be trivial (you can't store thousands of hashes for each account...) – Bakuriu Oct 14 '16 at 08:35
  • 2
    But I've read many times here and elsewhere that "In cryptography, the avalanche effect is the desirable property of cryptographic algorithms, typically block ciphers and cryptographic hash functions wherein if when an input is changed slightly (for example, flipping a single bit) the output changes significantly (e.g., half the output bits flip)." Doesn't the translation of small input changes to small output changes indicate a poor or unsuitable hash function? – cat Oct 14 '16 at 10:59
  • 3
    @Bakuriu True, although you don't have to store multiple hashes of the old password. You could just as easily hash different variants of the new one during the attempted password change. That's how Facebook supposedly does it, for instance (see http://security.stackexchange.com/a/53483/115393). – Disenchanted Lurker Oct 14 '16 at 11:04
  • 3
    When I say that the machine compares `old password` and `new password`, it does not compare them in hash form. It compares them in cleartext(but it does not store the cleartext form of password). And yes, avalanche effect is a desirable property of cryptographic algorithms. – pri Oct 14 '16 at 11:06
  • 1
    @cat the avalanche effect is irrelevant here. If you hash slight variants of the new passwords and you get the hash of the old password as result, then you know (i) what the old password is (ii) the new password is way too similar. – MauganRa Oct 14 '16 at 13:46
  • @MauganRa Your comment makes no sense; my point is that "*good*" hash functions should translate small input changes to large output changes, and so if you can tell the inputs are close by the fact the outputs are close, it must be a crappy hash function. – cat Oct 14 '16 at 14:09
  • 1
    @cat the point of my comment is that the avalanche effect does not come into play here. We look for _exact_ matches of the hashes of derivatives of the _input_. The only thing which makes the trick inpractical would be a _slow_ hash function. See drewbenn's answer. – MauganRa Oct 14 '16 at 14:40
  • @cat otherwise you're right. – MauganRa Oct 14 '16 at 14:42
7

This a common requirement. The rationale is that you have to change regurlarly your password in case it would have been compromised without you notice it (someone looking over your shoulder, etc.).

If the new password is too similar to the old one, an attacker could first try slight variation over the old one (I assume he was able to steal it beforehand). In your example, you only change the last numeric character : 10 tries maximum.

But this is not normally implemented by storing the old password in clear text! Everyone now knows that it is bad. Simply the change password forms requires the old password and the new one (repeated twice). That way:

  • the old password is controlled to make sure you did not leave your workstation still connected and someone is tricking you
  • the new password can be compared to the old one and will be rejected if it is too similar
  • the new password is entered twice to limit the risk of a typo

And only a hash of the password is stored...

Serge Ballesta
  • 25,636
  • 4
  • 42
  • 84