• Reliant1087@lemmy.world
    link
    fedilink
    arrow-up
    1
    arrow-down
    2
    ·
    1 year ago

    You could take the old password, change one or two letters and compare the hash to the hash of the new password?

    • psilocybin
      link
      fedilink
      arrow-up
      7
      ·
      1 year ago

      That’s the point though.

      You’re not supposed to have the old password. If you had the old password you could just compare it to the new password.

      The only way you can do it is to take the new password and make a hash for every possible single-character variation and compare them all to the old hash

      • abraxas@lemmy.ml
        link
        fedilink
        English
        arrow-up
        1
        ·
        1 year ago

        They shouldn’t be storing the old password hashed, either. Expired password hashes should be destroyed like any other potentially-sensitive information that is no longer business critical.

        There is a reason hackers look to get users tables even though the passwords are hashed. Because with enough of them and enough time, they can usually figure out plaintext. Giving them 10 previous hashed passwords for each user is just increasing the hypothetical risk.

        • psilocybin
          link
          fedilink
          arrow-up
          2
          ·
          1 year ago

          You’re right ofc if you wanted to make a general remark, but wrong if you thought that was what I was implying. Never store hash histories, kids!

      • Reliant1087@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        Sorry, that’s what I meant as well :) Came out upside down when I wrote. We used to figure out shitty ISP router passwords this way by having a table of common passwords and their hashes.