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?
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
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.
bcrypt has a maximum password length of 72 bytes.
https://en.wikipedia.org/wiki/Bcrypt#Maximum_password_length
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?
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
Damm, I legit didn’t knew there bcrypt had a length limit! Thank you for another reason not to use bcrypt
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.