The poster points out that bcrypt isn’t dependent on password length, but doesn’t point out that this will obviously be the case because bcrypt ignores all but the first ~72 characters of input. Both this limitation and the way in which it is typically implemented (silently ignoring the rest) are good reasons to avoid use of bcrypt. bcrypt may be reasonable to use if combined with a SHA-2 prehash, but that’s nonstandard and little supports it.
I did not mention it in my post, however, I did use passlib.hash.bcrypt_sha256.hash() in my benchmark. I’ve updated the post to reflect it.
For context, one can prehash the password with SHA-256, encode the result with base64, giving a 44-byte password (including the “=” padding), then send the final string to bcrypt as your “password”. Essentially, in pseudocode:
FreeBSD may also be affected
releng/11.1/lib/libcrypt/crypt-sha512.c
The poster points out that bcrypt isn’t dependent on password length, but doesn’t point out that this will obviously be the case because bcrypt ignores all but the first ~72 characters of input. Both this limitation and the way in which it is typically implemented (silently ignoring the rest) are good reasons to avoid use of bcrypt. bcrypt may be reasonable to use if combined with a SHA-2 prehash, but that’s nonstandard and little supports it.
I did not mention it in my post, however, I did use
passlib.hash.bcrypt_sha256.hash()in my benchmark. I’ve updated the post to reflect it.For context, one can prehash the password with SHA-256, encode the result with base64, giving a 44-byte password (including the “=” padding), then send the final string to bcrypt as your “password”. Essentially, in pseudocode: