I thought that part of the strength of bcrypt was that it hashed password many, many times, and that number of times through the hash is based roughly on the strength of the CPU doing the hashing. If this is true, wouldn't that make it all but impossible to brute force? You'd have to know how many times the passwd was hashed in addition to everything else.
The "key stretching" factor is configurable, but in the end you need to be able to check a login attempt in a reasonable amount of time (say, 1 second). So you have to be able to compute at least 1 hash/s on your production machine (probably much, much more to avoid performance problems).
If the attacker has access to 100 machines as powerful as your production box for 6 months, they can calculate 100 * 86400 (seconds per day) * 180 (days per month) = 1.5 billion hashes. Depending on the value and strength of the passwords, this could be worth doing. It's almost certainly worth calculating the hashes of the top 100000 most common passwords in any case
edit: > You'd have to know how many times the passwd was hashed in addition to everything else
As chill1 said, that's usually stored along with the hash. Even if it wasn't, you could see how long login attempts took you to figure out a rough number, then just check the hash of every iteration up to say that number * 2
This system here can brute force 180 billion MD5 hashes per second:
http://www.zdnet.com/25-gpus-devour-password-hashes-at-up-to...
[edit] If you only allow passwords to contain upper/lower case letters and numbers, at 1.5 billion MD5 hashes per 6 months, it would take 19 years to check up to and including 6 character long passwords. And because it's bcrypt, and each password has a different salt, you need to do that for each user; you can't build up a raintable as you go.