Many consecutive hashes to slow down brute force attack? I've heard that hash algorithms like bcrypt are more secure because they take longer to complete, and therefore take much longer to brute force, without a noticeable delay for legitimate users. Would using a faster algorithm, such as SHA-256, multiple times, be secure? For example:

hash = "password"
for x in range(5000):
    hash = hashlib.sha256(hash).hexdigest


As it has to hash the data, then hash the hash, and so on, taking much longer than a single SHA-256 hash, wouldn't this accomplish the same thing?
Instead of that home-grown scheme, I would use PBKDF2 instead if you simply are sold on the idea of iterated hash schemes. It uses an such a scheme, although not exactly the one you have described, and is well-studied and considered secure.

However, PBKDF2 doesn't offer many advantages over bcrypt, as PBKDF2 is still vulnerable to GPU and FPGA/ASIC brute-force attacks. bcrypt resists GPU brute-forcing because of the 4K table used in the algorithm, which forces contention for the global memory bus in GPUs. But bcrypt is still potentially vulnerable to FPGA/ASIC attacks, although most people don't have to worry about that.

A newer KDF, scrypt, is also tunable for the amount of memory it uses, so it is more resistant (when properly tuned) to FPGA/ASIC attacks than bcrypt. However, scrypt is relatively new (2009) when compared to bcrypt (1999), so that may make you somewhat nervous.

Essentially, to store passwords, you should be probably using bcrypt, since it seems to hit a sweet spot of being GPU resistant as well as being sufficiently mature. But PBKDF2 and scrypt are still good; using any one of the three is really fine.

For more information, I would recommend looking at the following question which has an (excellent) top answer by Thomas Pornin: Do any security experts recommend bcrypt for password storage? He is infinitely more credentialed than I am, so if you don't believe me, hopefully his testimony will be compelling.