I recently became aware of the fact that bcrypt truncates passwords to 72 characters. Practically speaking my intuition is that this does not pose any major security problems. However, I understand that it does mean any software libraries that use bcrypt potentially suffer from a "bug" where two ultra-long passwords that begin with the same 72 characters will be equivalent.
The authors of the Django web framework wrote something called
BCryptSHA256PasswordHasher to resolve this issue; what it does is first hash users' passwords with SHA256 before passing them to bcrypt.
Some devs on my team were debating the merits of this approach and I just wanted to collect thoughts from the general community. On the one hand, does this not in some sense reduce security by shrinking the total space of possible values being fed into bcrypt? SHA256 will always output 32 bytes, far short of the 72 (significant) bytes that we would have otherwise. On the other hand, without hashing passwords first we essentially have an unevenly distributed space where for every 72-character prefix, all passwords starting with that prefix collide.
My gut feeling is that the distribution issue past 72 bytes is unimportant and that
BCryptSHA256PasswordHasher really isn't useful. That said, I also recognize that, generally speaking, frameworks that are as popular and widely-used as Django tend to take these things seriously and have good reasons behind their decisions. So I don't really have much confidence in my gut on this one, if that makes sense.
Am I wrong? Does hashing passwords with SHA256 before bcrypt not reduce security, even theoretically? Is the distribution problem more severe than I realize? Is there something else that I'm just completely not thinking of?