Presumably you will use a key-stretching algorithm before applying HMAC.<p>[edit]<p>So yes, directly using a password in HMAC is a bad idea, and less secure than using some function designed for deriving keys from passwords.<p>You are confusing two things about sha-1.  Assuming a 100% secure cryptographic hash function that is as fast as sha-1, you should <i>not</i> use it directly for hashing passwords (though it can be part of a larger construction like PBKDF2).<p>This is because the number of passwords you can check per second in an offline attack is related to the speed of the hash function, and bcrypt (and pbkdf2, and scrypt, argon2) are all various ways of slowing down the hashing process.<p>Similarly it is likely that md5 would be roughly as secure for protecting passwords as sha-256 when used in pbkdf2 because the known weaknesses of md5 would not be of assistance in performing a dictionary attack against a hashed password.<p>If you have a high-quality key then HMAC is secure without needing the hash function to be slow, so if you wanted to use a password with HMAC, you would first use a KDF to generate a high-quality key from the password, and <i>then</i> use the key in hmac.  This is similar for any cryptographic tool that wants a high-quality key as input (i.e. most of them).<p>[edit2]<p>A shorter answer is that HMAC is secure and fast because its input key already has sufficient entropy.  bcrypt is slow because its whole point is to make it difficult to attack a key with low entropy.