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.
$\begingroup$
$\endgroup$
2
-
1$\begingroup$ Bcrypt is good for hashing passwords. For hashing high entropy tokens I'd use SHA-2. $\endgroup$– CodesInChaosOct 4, 2015 at 11:29
-
$\begingroup$ (Also, bcrypt does not encrypt.) $\endgroup$– user991Oct 4, 2015 at 11:39
Add a comment
|
1 Answer
$\begingroup$
$\endgroup$
2
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.
-
-
$\begingroup$ @CodesInChaos, depending on token length that could mean multi-target attacks are somewhat feasible. But with e.g. 192 bits, sure. $\endgroup$– otusOct 5, 2015 at 11:24