Why should I hash passwords?

For any reason, your database may be compromised and its data may be obtained by someone else. If the passwords are in what we call plain text, you will have leaked a piece of sensitive information that your users have trusted you with: their password (which is very likely to be a password shared in multiple services). This is a very serious issue.

Instead of plain text, passwords are typically hashed with an one-way hashing function. If the cryptographic function used for the hashing is strong, then the passwords are much safer, because even if someone gets their hands on your database, it's computationally infeasible to calculate the passwords (given only the hashes).

On the other hand, the hashed information remains useful to you: Because the same hash function will always yield the same hash for the same input, you can still hash any attempted password and compare the result to your saved hash to verify a user's authentication attempt (without knowing the correct password beforehand).

Of course, just hashing is not enough nowadays. There are lookup attacks that often make decryption (of hashes created from predictable passwords) very feasible. To counter these attacks, each password is hashed together with a unique randomly generated piece of input (called salt). The salt is stored in plain text in the database and it doesn't have to be secret, because its main purpose is to render precomputed hash dictionaries useless.

Almost all serious platforms use hashing and salting to store their users' passwords (unless they make use of something different but comparably secure that I'm not aware of). Incidentally, this is exactly why you can reset your password in various services but almost never recover it: The hash can be overwritten by the system, but it can't be decrypted.

You should by all means do the sane thing for the sake of your users' security and salt-and-hash your passwords. There are plenty of resources online that explain the process and the pitfalls in detail. One of them is "Secure Salted Password Hashing: How to do it Properly".

Your database could be compromised for any number of reasons, it happens all the time watch the news (even to some of the biggest web sites on the web). It's just a safety precaution to your users to hash their personal information in case your DB ever gets compromised for any reason.

The most basic reason why you hash a password is so that if the stored version of it is stolen it cannot be openly read.

Note that I said the stored version - if the password is never stored in any form (which is unlikely) then there is no point hashing it ever. But it is unlikely (and impractical) that you will never store it, so it should be hashed. You may think that your database is secure but there are some very smart people out there who are way smarter than you.

But you should also note that hashing it alone is largely ineffective - you should also add a salt to it before hashing. This means you add a known (preferably not too predictable) value to the password (anywhere in the password) before hashing it - this helps to slow down the breaking of the password by the use of rainbow tables.

Transmission of the password should be across a connection secured by TLS - ie it should be across HTTPS. This way you can send the entered password in clear text (you should not try to encrypt or hash it at the web page), the server side code then salts and hashes the received password before checking the resulting hash against the salted hash stored in the database.