Bcrypt input length vs collisions I am currently implementing oauth2 bearer token authentication and am storing the tokens bcrypt encrypted. My question is how long should the tokens be to achieve maximum security. E.g. at what length would longer tokens be useless since a bcrypt collision is as likely as guessing the token.
The bcrypt algorithm generates a 192-bit password hash by encrypting three 64-bit blocks using a password-derived blowfish key. The common format for storing bcrypt hashes, however, only includes 184 of the output bits.

If bcrypt was a "perfect" 184-bit hash, finding a some preimage would take the same amount of work as a brute force attack on a 184-bit key. So if you had random binary tokens, a token longer than 184 bits would be useless. Similarly, with a random hex token, length over 46 characters would be useless, etc.

Many bcrypt implementations also have a limit on input length. This is usually at least 51 bytes, so if your input format is hex, base 64 or binary, the above limit would be reached first. If you were hashing some less dense encoding, like decimal numbers (or indeed passphrases...), it might not be.

However, if your tokens are high entropy (e.g. 128+ bits) there is no need to use bcrypt. Bcrypt is useful for slowing down a brute force or dictionary attack, but 128 bits is enough that such an attack would be infeasible. A key derivation function such as HKDF, or even a simple salted hash, would be sufficient.