582
Uh oh, somebody's not following best practices, that's a paddlin (thelemmy.club)
submitted 1 year ago by to c/cybersecuritymemes@lemmy.world
106 comments fedilink hide all child comments
 
you are viewing a single comment's thread
view the rest of the comments
[–] 28 points 1 year ago (4 children)

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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 8 child comments
    •
  • [–] 6 points 1 year ago*

    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.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 6 points 1 year ago

    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.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 2 points 1 year ago* (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 12 points 1 year ago (1 child)

    Why wouldn’t it work?

    You’re removing the last character before hashing, so the removed character won’t affect the hash value.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 1 year ago (2 children)

    Because

    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".

    Now here are those 3 "passwords" hashed.

    • 5c30739dfd7a5df387f9a3e6c08a026831314e8cc8df4f18e3c2a7baddf30bb2
    • a78cb4f0ddf5513862e97e20fe8f331d08bbb5aacf0ac14c0b6a0f1b036a7b6b
    • 9385bd96fb795abd7204d27990e8c7b2bf929bac772b6f8e3b875e8a313be5cb

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 20 points 1 year ago (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •