0

I've seen it mentioned a number of times here that an approach to preventing forced password changes from being changed to trivially similar passwords (eg, mysecurepassword1 gets changed to mysecurepassword2 and so on) is to hash multiple variations that can be later compared to. That can be done by looking for patterns and doing things like incrementing numbers, adding them, etc.

I'm curious what the implications of this is on security. These hashes would give more opportunity for a brute forcer, wouldn't they? They're essentially collisions. Although on the other hand, you'd expect that if someone is brute forcing, they'd probably try the varitions around a similar time, so it seems like it wouldn't necessarily save much brute forcing time. I'm also unsure how much even collisions would matter if the password is secure enough. Eg, if we have 10 variations hashed, that theoretically means that it would take 10x fewer attempts to brute force the password, right? But the scale of magnitude of time that is needed to brute force a secure password is often so large that even a 10-fold decrease is still an impractically large length of time.

So yeah, does hashing these variations significantly weaken security? Is it small enough that it doesn't matter (particularly compared to the benefits of avoiding similar password reuse)?

Kat
  • 411
  • 3
  • 12
  • 1
    I think it might be more secure to see if the new password provided, when trivially changed, hashes to the stored value - you provide "Password7", and the change routine hashes "password7", "Password6", "Password8", etc with the old salt, and sees whether they match the stored value, rejecting the input if they do. Although it would be better yet to compare the old and new values, since you're asking for the old password to allow changes, yes? :-) – Matthew Jun 22 '17 at 16:36

5 Answers5

3

If there is any impact on technical aspects of security, whether positive or negative, it appears to be very marginal. I qualify "technical" because human/psychological elements often play a significant role.

The real impact is only the real user - whose life is made marginally difficult and perhaps on the plus side, more security aware.

From the server side, I see this as extra work (both during development and operations) that doesn't quite give enough benefit to justify it. To defend against any moderately talented attacker's dictionary attack, the number of hashes that need to be stored this way is too large to make sense at scale.

Why? The attacker's work factor hasn't changed much, despite you having eliminated "some" of the combinations.

OTOH, user awareness can be better handled on the client side by rating the password strength while the user types it in. This can include both entropy tests (length, variety, etc) as well as uniqueness tests (variation of previous password). No need to store it on the server side, IMHO.

Sas3
  • 2,648
  • 9
  • 20
  • To be clear, I'm not really interested in the user implications. I have no intention of forcing user's to change passwords. What I'm curious about is solely the security implications of storing hashes of variations of the user's password. – Kat Jun 22 '17 at 17:52
  • That said, I feel like there is a real use case for the described model. Eg, if you have genuine worries that the DB might have been compromised, you're gonna want everyone to change their password. And you do NOT want them to change it to a very similar password. Of course, this requires foresight as the "variation hashes" have to be generated on sign up. But yeah, you're right that this could be done client side. Client side can be bypassed, though. Then again, why would do that? The obvious answer that comes to mind being those with JS disabled. – Kat Jun 22 '17 at 17:54
  • On JS-disabling: Yes, that's something to consider. On bypassing client side: We're talking about genuine users in this case, aren't we? If they are working to bypass security measures (client side checks) we probably have a much bigger problem on hand. On "you do NOT want them to change it to a very similar password" - True, but if you step back a bit at take a look, effort vs benefits still looks skewed to me. Of course, YMMV. :) – Sas3 Jun 23 '17 at 01:46
  • As an aside, I'm not sure why I thought all those client-side tests would have to be only client side. Naturally we can do them server side, too, hashing the password only after confirming it's sufficiently strong. – Kat Jun 23 '17 at 14:49
2

Remember, you needn't store variants at all.

In case you want the new password to match the one previous password, you can ask the user to enter both when changing it, and measure the minimum edit distance between the pair.

Of course, many would recommend not doing anything with passwords except hashing it. In that case, you could simply generate all variants of the new password, and compare the hashes with that of all old passwords (without needing to store all the old variants).

At no time will you store variants of passwords, or their hashes, while still performing basic similarity checks.

Jedi
  • 3,936
  • 2
  • 24
  • 42
  • 2
    That's a great idea. Now I'm unsure why anyone would ever recommend storing hashes of similar passwords. – Kat Jun 23 '17 at 14:47
  • A reason could be that certain password transformations are one-directional and you need the plaintext of all the old passwords to generate the list of variants. – Jedi Jun 23 '17 at 19:07
1

I'm curious what the implications of this is on security. These hashes would give more opportunity for a brute forcer, wouldn't they?

I think not, the system will be checking the one password they chose. The brute forcing will only be attacking that. The alternative versions will only be used when a user changes their password.

Even if the attacker could conduct an offline attack against all variants at their leisure, they would still probably just attack the one as they gain nothing by brute forcing against each hash with every attempted plaintext.

They're essentially collisions. Although on the other hand, you'd expect that if someone is brute forcing, they'd probably try the varitions around a similar time, so it seems like it wouldn't necessarily save much brute forcing time.

They are not collisons at all - these are when two plain texts have the same hash. Each variant will have a totally different hash to the other. No one would be able to tell that the plain text was similar in anyway.

I'm also unsure how much even collisions would matter if the password is secure enough. Eg, if we have 10 variations hashed, that theoretically means that it would take 10x fewer attempts to brute force the password, right?

Sorry but wrong, as said the authentication protocol will only be checking the one password the user chose, and secondly a 10x would not be the case even if it did check all variants as its not 10 times fewer attempts.

So yeah, does hashing these variations significantly weaken security? Is it small enough that it doesn't matter (particularly compared to the benefits of avoiding similar password reuse)?

So to sum up. If the authentication protocol checks only the chosen password by the user, then no. Even if it did check all variants it still would only lower the entropy by a relevantly small amount. The hashes would also share no common structure to each other, so even with access to the hashes you be none the wiser.

Can I also add, the above is based purely on the question the OP asked. But we know that hashing passwords is obviously not good, so for fullness even if the passwords were 'hashed' using a suitable Password Based Key Derivation Function, the answer would still stand.

ISMSDEV
  • 3,272
  • 12
  • 22
  • "the system will be checking the one password they chose" Why would that be the case? I'm assuming that the attacker has some sorta offline DB, in which case they might simply check each brute force attempt against every hash in the DB. You seem to assume going through some authentication protocol, but I assume avoiding that, as going through, eg, some login screen would be too slow. – Kat Jun 22 '17 at 17:48
  • "They are not collisons at all - these are when two plain texts have the same hash" I know, they're not collisions, but they're *like* collisions. Once you find one of these variant hashes, you should be able to easily find the real password, since it is just a small variation away. Eg, if you find the variation `mysecurepassword2`, then you can guess that the real password might have been, eg, `mysecurepassword1`. – Kat Jun 22 '17 at 17:49
  • But my point is you will not find the variant hash and it's plaintext. If you could it would be just as quick to find the original. The fact you have a few variants makes no real difference to the speed of brute force. Certainly not anywhere near 10x not even close. – ISMSDEV Jun 22 '17 at 18:02
  • Plus sorry but as a cryptographer saying it's like a collision is not correct at all. Not in anyway. – ISMSDEV Jun 22 '17 at 18:22
  • I disagree with some of your points. I think @Kat has a point about how checking hashes against all variants can speed up cracking time. That will be a legitimate vulnerability, so long as the attacker understands what the variants **mean**, they can speed up cracking for some passwords. My reasoning is that the hashing is what takes the most time, so you would compare against alternates. If I hash "password" and then find a match against an alternate, I know that the real password is a simple variant on "password". It is downhill from there, because the variants gave me some free matches. – Conor Mancone Jun 22 '17 at 19:28
1

I'm curious what the implications of this is on security. These hashes would give more opportunity for a brute forcer, wouldn't they? They're essentially collisions.

I don't see how they are "collisions" in any sense of the term.

Although on the other hand, you'd expect that if someone is brute forcing, they'd probably try the varitions around a similar time, so it seems like it wouldn't necessarily save much brute forcing time.

And this remark of yours, it seems to me, all but answers the question. We can appeal to Kerckhoff's law to reasonably assume that the cracker will know about your multiple-hashing technique—which mutations you apply to the users' passwords, which entries are such mutations for which real entry, etc. So the simplest solution for the cracker is to just ignore all the hashes for mutated variants and concentrate on the real passwords.

So in the worst case, where we maximize the attacker's knowledge, the additional hashes have zero effect on security.

Luis Casillas
  • 10,361
  • 2
  • 28
  • 42
0

NIST has recent release a new DRAFT of password guidelines. Sopho's blog does a good job of explaining the changes in plain terms.

In short, you shouldn't need to store multi HASH's, because:

  • Your HASH should be salted using a strong algorithm and each instance of that HASH should be completely different, making comparing them moot.
  • NIST recommendations have the developer comparing passwords against a known dictionary.

Password Length

What we know is that password length becomes more important than, arbitrary complexity rules. The reason for this is, the amount entropy of the password is not defined by a users password, but by the allowed symbol set a developer give the user for creating a password.

A larger symbol set increase the bit's of entropy.

Dictionary Passwords

The big move is put the security on developers. This includes checking a users password against common password sets from a dictionary. This does two things, it drastically reduces the attack surface. Attackers would be limited to the largest dictionaries (computing power), and brute forcing 8+ char passwords is unreasonable for most attackers.

Ad to that you can develop password rule sets pragmatically to look for any dictionary password. e.g. If you a password was IAmTheWalrus, your diction might spot Walrus and tell the user that the password contains a dictionary word. They might enter IAmTheWa!rus, but a 12 char password like that is magnitudes better than common dictionary attacks.

Shane Andrie
  • 3,810
  • 1
  • 13
  • 16