To be fair to Alpha, SHA1 is a really shitty password hash. (Use bcrypt, scrypt if you're feeling adventurous, or salted SHA1 with a configurable number of iterations if you really can't do better.)

Absolutely, but tons of places still use it (and md5 shudder), and you rarely know what hashing algorithm a place is using when you sign up. So when picking a "secure password" you should probably assume the worst.

You rarely even know if they store it in plan text.

If you're going to go the iterations route, instead of rolling your own, use PBKDF-2 which is documented in RFC-2898 and RFC-6070.

Is there documentation of best practices for using PBKDF2 as a password hashing function anywhere? I've switched to it as a more standard/better supported alternative to bcrypt, but information on this use case is worryingly scarce.

Even high-profile applications sometimes use weak password hashes. For example Windows passwords can be cracked at a rate of 8.27 billion password/sec on a Radeon HD 5970 graphics card, because the NTLM hashing algorithm is weak (simple raw MD4 hash of the Unicode password string). All Windows versions from NT4 to 2008 R2 are vulnerable.

http://hashcat.net/oclhashcat/

Can't a service throttle the login attempts, though? Or are we talking about trying to reconstruct passwords from a stolen database?