For password-hashing, you should not use a normal cryptographic hash, but something made specially to protect passwords, like bcrypt.
See How to safely store a password for details (this article advocates the use of bcrypt).
The important point is that password crackers don't have to bruteforce the hash output space ($2^{160}$ for SHA-1), but only the password space, which is much much smaller (depending on your password rules – and dictionaries often help). Thus we don't want a fast hash function, but a slow one. So your not too computationally expensive requirement is actually not possible to met. Bcrypt and friends* are designed for this.
*Bcrypt and friends: All slow hash functions. There is PBKDF-2 (which basically just iterates a fast hash with salt some configurable large amount of rounds, and thus the brute force can be easily parallelized - but it is mentioned in a NIST standard, which might be important for certain uses), bcrypt (which additionally needs 4 KB of memory, which makes parallelization (of the brute force) on standard GPUs quite slow, but can be still attacked on custom hardware with 4KB cache per processing unit), and scrypt (which takes not only a configurable amount of time, but also a configurable amount of space to execute (with a possible trade-off to time), and thus brute-forcing can not be easily (cheaply) parallelized).
Of course, you always should use a salted hash (a salt is automatically included in bcrypt). A salt is stored together with the hash in the database (e.g. it is not more secret than the hash), and will be hashed together with the password to produce the hash.
A salt alone does not help against a brute-force attack against specifically your password, but it helps against rainbow table attacks (i.e. attacks with precomputed hash lists), which can attack with the same effort all passwords everywhere at the same time, instead of only all passwords with the same salt (which should be about only one).
There is also the concept of a "secret salt" (also known as pepper), which is not stored together with the password, but at some other location not accessible by a possible attacker. (You would then usually use the pepper, as a non-user-specific piece of information, together with a normal salt.)
This does work only for some attack scenarios, where the attacker does have only (reading) access on the database (or maybe some less secured backup copy on it), but not on this pepper data (i.e. we have an attacker who can't yet execute arbitrary code on the server).
Another possibility would be to use some kind of cryptographic hardware (a token) attached on the server with an embedded key, which does some hashing operation on salt, key and password to produce the hash. Make sure to rate-limit this in case it is stolen, and make sure it does not have an interface to retrieve the secret key, otherwise your attacker (if she succeeds to gain execute access on the server) can use this, too.