While using bcrypt is great, it is not uncrackable.
It is still vulnerable to brute force attacks. If you have a strong password it wont be cracked, but most people don't
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.
Strong hashes prevent bruteforcing millions of combinations, but that actually depends on the attacker needing to try millions of combinations.
The problem is it's impossible to protect weak passwords, because attackers can just run a password database through your hashing algorithm and see if there are any matches.
i.e. Just because you can't reverse a hash to get the password, doesn't mean you can't hash a bunch of passwords to figure out which leads to which hash
So salts are certainly the way to go, as, although they're "known" (appended to hash, or stored elsewhere in DB), the hash can't be compared to a generic table, it'd need to be a full dictionary table of hashes already encrypted with that salt (which theoretically/hopefully is used only once)?