Following on from Baget's answer. The reason you hash passwords is to avoid you having to store the plaintext password for authentication.
Instead you store the hash of the password.
Your authentication/login process then becomes something like this :
User enters password.
Hash the password they have input.
Compare the entered hash against the stored hash.
If hashes match then password is valid so user is authenticated.
The reason this is done is to protect your users' authentication details. So if your password file or database did become public domain somehow then a malicious user couldn't pretend to be a genuine user.
So the nature of the hashing function means it's one way and so the original plain text can't be recovered.
That's the theory, of course in practice it gets more complicated than that.
Most users tend to use passwords that they can easily remember so this means that all your best efforts at security can come to nought because if someone obtained your password file/DB then offline they can build a dictionary of common words and brute force iterate and hash until they find a matching hash in your list.
To avoid this, many people use a 'salting' technique where the password has a short cryptographically 'random' string added to the password before hashing. Read this for more details
The other issue here is the strength of your hashing algorithm - you need to ensure that you can't create 'collision's i.e two pieces of plaintext that produce the same hash value.
Many older hashing algorithms such as MD5 and SHA1 are increasingly looking vulnerable in this regard.
MD5 considered broken
SHA1 also considered broken
Hope that helps and I realise that's probably a bit more than your were asking but I think it's important people understand security issues when implementing authentication code