Like MD5, SHA1 is designed to be fast. For that matter, so is SHA256, and all the SHA-3 candidate functions. The right way to think about this is that all the strong crypto hash functions are unsuitable for use by themselves as password hashes.
Cryptographers have a mechanism for securely turning human-readable text into secret material: key derivation functions. All the modern KDFs are adaptive, meaning that they come with a "pain" dial that you can turn to force attackers to spend more time executing crypto code paths and less time comparing results.
You can build decent KDFs out of functions like SHA1, but if hardware GPU cracking is the future, you're best off with something like Colin Percival's "scrypt", which was explicitly designed to be memory-hard (requiring lots of state to compute) and hard to parallelize:
I know you're a domain expert and in this thread you've suggested both bcrypt and scrypt. Is there any advantage to one over the other? From my POV it seems that bcrypt has more implementations and seems better-known (in a good way).
Cryptographers have a mechanism for securely turning human-readable text into secret material: key derivation functions. All the modern KDFs are adaptive, meaning that they come with a "pain" dial that you can turn to force attackers to spend more time executing crypto code paths and less time comparing results.
You can build decent KDFs out of functions like SHA1, but if hardware GPU cracking is the future, you're best off with something like Colin Percival's "scrypt", which was explicitly designed to be memory-hard (requiring lots of state to compute) and hard to parallelize:
http://www.tarsnap.com/scrypt/scrypt-slides.pdf