Why are common hashing functions such as md5() and sha1() unsuitable for passwords?

Suppose the developer chose SHA1 to ‘encrypt’ his user’s passwords.
The string mypassword would hash into 91dfd9ddb4198affc5c194cd8ce6d338fde470e2 and I can not reverse the process to get  mypassword back because SHA1 is a one-way hash.
Or is there? Well, since SHA1 (and MD5) were designed to be very computationally efficient, one could quite easily use brute force to calculate it by trying literally millions of hash calculations.
Ok, then what is the problem? It will take a lot of time then to try out all these millions of combinations… Well, http://www.golubev.com/hashgpu.htm does around 2300.000.000 SHA1 hashes per second and about 5600.000.000 MD5 hashes per second (and these numbers are with2 year old graphics cards… so that number should have risen to almost double by now, take a look at Implementations of Hash Functions SHA-1 and SHA-512 So, let’s do some math… and then you will simply see what kind of security you have implemented (we deal with the ‘salt’ later on): - Most passwords only use alphanumeric characters with upper and lowercase mixed (though more often than not it is all lower).
That gives us62 characters.
- Most passwords are only the minimum required length of8 characters.
- This gives us 62^8 =218.340.105.584.896 combinations - A single brute force search will take about 26.37 hours (remember, this is just one single GPU… a hacking team probably has more).
- That means in about1 day we have the full complement of possible combinations and we can ‘decrypt’ most of the passwords - This is all done without a dictionary… a dictionary contains most commonly used words and can speed up the process quite a bit.
But why would we want to?