Bcrypt was not designed to counter rainbow tables. Although the internal salt does provide that defense. Bcrypt was designed to protect against raw brute forc

Bcrypt was not designed to counter rainbow tables. Although the internal salt does provide that defense. Bcrypt was designed to protect against raw brute force: See: http://static.usenix.org/events/usenix99/provos/provos_html/bcrypt.html http://static.usenix.org/events/usenix99/provos/provos_html/... > "At the time of deployment in 1976, crypt could hash fewer than 4 passwords per second. Since the only known way of inverting crypt is to guess preimages, the algorithm made passwords very difficult to recover from their hashes--so much so, in fact, that the designers of UNIX felt comfortable leaving the password file readable by all users. Today, over 20 years later, a fast workstation with heavily optimized software can perform over 200,000 crypt operations per second. Attackers can now expediently discover plaintext passwords by hashing entire dictionaries of common passwords and comparing the results to entries in a password file." > "While salted passwords defeat lookup tables, given a particular salt and hash, an adversary can still mount a brute force attack by evaluating F(s,t) on every possible password. It follows that the best security one can achieve is $\epsilon\approx 1/\vert F\vert$, where |F| is the cost in gates of implementing F. Usability requirements therefore effect a lower limit on $\epsilon$--if people can only tolerate a one second delay for checking passwords, F can take at most one second to evaluate. F should not take significantly less, however, as this would unnecessarily weaken security." > "The number of gates |A| that an adversary can reasonably muster for an attack increases constantly as hardware improves. Fortunately, so does the speed of machines that must legitimately evaluate F. That means passwords should not be hashed by a single function F with fixed computational cost, but rather by one of a family of functions with arbitrarily high cost. Instead of repeatedly throwing out functions like crypt and MD5 crypt to start over with more expensive but incompatible ones, systems should allow the cost of any password manipulation software to scale gracefully with a tunable parameter. Thus, $\epsilon$ can decrease as fast as hardware improves and users will tolerate. Compromised password databases will then enjoy maximum security against off-line attacks." The purpose of bcrypt was to allow for a single algorithm that can be tuned for existing speed of existing computers to produce a "slow" algorithm. Then, as Moore's law makes computers faster, bcrypt can be progressively slowed to keep pace, so that performing a brute force still takes an unreasonable amount of time.