From their CTO (on Disqus in response to my question):
"The salt, pepper, and password were concatenated together to form the string that was in turn passed to the hashing function."
40 + 40 + strlen($password) > 72
Uh-oh.
PHP. This is a known weakness in PHP's bcrypt implementation. From Wikipedia, "Many implementations of bcrypt truncate the password to the first 72 bytes." I would hope that they're using a competent implementation that either supports longer passwords or throws an error if it's asked to hash a longer password.
Besides, bcrypt takes the salt as a separate parameter anyway. So it doesn't really make sense in context that the salt, pepper, and password were concatenated and passed to bcrypt. Perhaps he was talking about the SHA-1 stretching; perhaps they hash the passwords with SHA-1 before passing it to bcrypt.
I don't think we know enough to conclude that they were definitely doing it wrong, but it would be nice to know more details about the algorithm, though.
Actually, it's a known weakness in BCRYPT. PHP did not implement bcrypt, it was ported in via crypt(3). Meaning that ALL versions of bcrypt have this issue.
Some implementations error on > 72 bytes, but NONE of them accept longer passwords.
> I don't think we know enough to conclude that they were definitely doing it wrong, but it would be nice to know more details about the algorithm, though.
Given what has been shared so far, there's enough signs pointing that the chances are pretty high they did something wrong. 40 byte salt? Bcrypt only supports a 128 bit salt. So either they did something silly custom (at which point it's no longer bcrypt), they aren't actually using bcrypt, or they did something silly like concatenate the salt + pepper + password and pass it to the password field.