Just take the string as bytes and hash it ffs

    • owsei@programming.dev
      link
      fedilink
      English
      arrow-up
      4
      arrow-down
      1
      ·
      2 months ago

      Damm, I legit didn’t knew there bcrypt had a length limit! Thank you for another reason not to use bcrypt

      • frezik@midwest.social
        link
        fedilink
        English
        arrow-up
        4
        ·
        2 months ago

        Scrypt has the same limit, FWIW.

        It doesn’t matter too much. It’s well past the point where fully random passwords are impossible to brute force in this universe. Even well conceived passphrases won’t get that long. If you’re really bothered by it, you can sha256 the input before feeding it to bcrypt/scrypt, but it doesn’t really matter.

    • Swedneck@discuss.tchncs.de
      link
      fedilink
      English
      arrow-up
      1
      ·
      2 months ago

      wouldn’t you then just break it up into chunks of 72 bytes, hash them individually, and concatenate the hashes? And if that’s still too long, split the hash into 72 byte chunks and repeat until it’s short enough?

      • yhvr@lemm.ee
        link
        fedilink
        English
        arrow-up
        2
        ·
        2 months ago

        I don’t know the specifics behind why the limit is 72 bytes, but that might be slightly tricky. My understanding of bcrypt is that it generates 2^salt different possible hashes for the same password, and when you want to test an input you have to hash the password 2^salt times to see if any match. So computation times would get very big if you’re combining hashes