Good salt for sure is always needed no matter what the crypto when you look at this type of attack method. As really the salt is the only strength no matter what algorithm.

– The goal of a salted hash is to protect against offline brute-force attacks (attacker has access to the database and the hashes). It’s worth noting that the ideally the salt should be different per user. Otherwise the attacker can generate a set of rainbow tables for that combination (@hash + word) for a dictionary, relatively easily. With per-user hashing they need to start from scratch for each user (so no point in creating a rainbow table as it’s no faster than a straight brute-force)

Also the length of the hash doesn’t (IMO) increase the time required to create the rainbow table (assuming that the attacker has access to the hash, which if they’ve got access to the database is a reasonable assumption).

– Also on the point of password strength, it’s worth noting that if people choose simple dictionary words for passwords then no matter how slow the algorithm you choose, if the attacker just has to create ~50,000 hashes (a typical large password dictionary) then they’ll be able to do that… One option might be to provide some advice to users about creating mnemonic passwords as a good route to create easy to remember passwords that aren’t going to fall to a dictionary attack.

If an attacker gets hold of your database, he can use a modest GPU to crack SHA1 at about 70 million hashes per second. I’m not aware of any GPU bcrypt crackers; he might manage a few hundred per second with the same resources, and even if he has an FPGA to play with he’s not going to do much better than that.

Sure, you can make the login delays fake, but why deliberately pick the solution that’s a million times weaker for a similar amount of implementation effort?

scrypt is an even more secure alternative, since it’s not just processing-hard, but memory-hard, thus eating up even more gates on an FPGA and limiting possible concurrency on a GPU (if you can even implement it there).

@Dan: That’s assuming there are no weaknesses in SHA-1 to exploit. In practice there are, and the exploits will probably become better over time.