I can imagine one legitimate case: when you create a password, they save the hash for the full password as well as the hash for the password without the last character. So if you attempt to change only the last character, they can detect it. They’d need to salt the two separately though.
In theory, they could do the same for every character, but they’d have to save 20+ combinations for that (plus all the salt), so I doubt anyone is doing that.
The strongly recommended hashing algorithms are slow on purpose, and often use up a lot of RAM, too. Multiplying the number of hashes you would need would multiply CPU/memory load for every new password.
Cryptographic hashes don’t work like that. One of the defined properties of a strong cryptographic hash is that changing even one bit on the input results in about 50% of the bits of the output getting flipped in a non predictable way. There’s simply no way to tell from looking at two cryptographic hashes how similar their inputs are. If there were, that would weaken the security significantly.
they save the hash for the full password as well as the hash for the password without the last character. So if you attempt to change only the last character, they can detect it.
is not how hashing works. You can’t create a subset hash to compare against the set hash.
Let’s say my password is “ILoveUsingSimplePasswords1”.
You remove the last character and get “ILoveUsingSimplePasswords”.
And then I change the password to “ILoveUsingSimplePasswords2”.
Can you tell which of the 3 is “ILoveUsingSimplePasswords” and can you identify where I’ve added 1 or 2 to the end? You can’t because it’s not how hashing works.
This is not what he meant. If the password is xyz he stores the hash (f*) for xyz and xy. When you change your password to xyb, it compares fxyz to the first saved hash and a truncated fxy to the second saved hash, flagging if you’ve only changed the last character. The mask length could be arbitrary and there can be many saved hashes at the expense of making password resets slow.
Yep, that’s what I meant. Pretty sure my company does this, because they can detect this, and I know enough of our IT to believe they’re not storing passwords in plaintext.
You didn’t remove the last character of “passwords2”. When you remove the last character, that becomes “passwords” and therefore has the same hash as “passwords1”[:-1]
I can imagine one legitimate case: when you create a password, they save the hash for the full password as well as the hash for the password without the last character. So if you attempt to change only the last character, they can detect it. They’d need to salt the two separately though.
In theory, they could do the same for every character, but they’d have to save 20+ combinations for that (plus all the salt), so I doubt anyone is doing that.
The strongly recommended hashing algorithms are slow on purpose, and often use up a lot of RAM, too. Multiplying the number of hashes you would need would multiply CPU/memory load for every new password.
No need to store it, you can do the opposite, create 20 variations of the new password, hash them, check if any match with the old password.
Edit : nevermind, it would only work if they added data instead of editing it.
Cryptographic hashes don’t work like that. One of the defined properties of a strong cryptographic hash is that changing even one bit on the input results in about 50% of the bits of the output getting flipped in a non predictable way. There’s simply no way to tell from looking at two cryptographic hashes how similar their inputs are. If there were, that would weaken the security significantly.
Why wouldn’t it work?
You’re removing the last character before hashing, so the removed character won’t affect the hash value.
Because
is not how hashing works. You can’t create a subset hash to compare against the set hash.
Let’s say my password is “ILoveUsingSimplePasswords1”.
You remove the last character and get “ILoveUsingSimplePasswords”.
And then I change the password to “ILoveUsingSimplePasswords2”.
Now here are those 3 “passwords” hashed.
Can you tell which of the 3 is “ILoveUsingSimplePasswords” and can you identify where I’ve added 1 or 2 to the end? You can’t because it’s not how hashing works.
This is not what he meant. If the password is xyz he stores the hash (f*) for xyz and xy. When you change your password to xyb, it compares fxyz to the first saved hash and a truncated fxy to the second saved hash, flagging if you’ve only changed the last character. The mask length could be arbitrary and there can be many saved hashes at the expense of making password resets slow.
I get it now. They’re comparing only trunks because the hash of the trunk wouldn’t change.
Yep, that’s what I meant. Pretty sure my company does this, because they can detect this, and I know enough of our IT to believe they’re not storing passwords in plaintext.
You didn’t remove the last character of “passwords2”. When you remove the last character, that becomes “passwords” and therefore has the same hash as “passwords1”[:-1]
Yeah, but 99.999…% of the time, they’re just storing plaintext.
I dunno about that, probably more like 99.98%.