Are you trying to do this with an object oriented approach? Here's my login_success() function from an old user object. This is being called with an associative array $record which is generated at login, and the password being stored isn't the password the user entered, but actually the encrypted password minus the salt.

***edit for clarification***
do not store your users' passwords as plain text, or even reversible encryptions thereof. The user table supporting the function listed had a 'password' field that contained the md5'd sha1 of the password they entered and a random salt which was stored in another field.

Basically when a user signed up and created their password, a salt was generated, added to their entered pass, and then the concatenation was sha1'd. THAT result then had the salt added to it again, and was md5'd. The result of that was stored in the password field. At login time, the record is loaded first behind the scenes based on username or email, and the attempted password goes through the same hashing procedure with the same salt, and success is determined based on whether they match. On success the function above is called to load relevant fields into the session, and create a cookie if they wish to be remembered.

md5 alone is not secure enough of an encryption, because of the proliferation of rainbow tables on the net, you can unfortunately often un-md5 just by googling the hash. can be confirmed by changing the literal string in the $badPass assignment below:

The site i'm redirecting to for the answer above was just the first result on google when i searched for the hashed value of the password.
Because md5 is so secure, it really can't be relied upon to protect anything but the most trivial of data. So what a lot of people will do, like I do, is use md5 as a wrapper around a better one way encryption like bcrypt, sha1, etc.
A salt is a random variant that complicates the algorithm a bit. Say you use a fixed string, 'salt' as a salt. you would take the string to be encrypted, and add the salt, then encrypt, and then either store the salt somewhere in another field, or tack it onto the end again. personally I like to use md5 after another encryption or two, then add the salt to the end of the result, because md5 results will always be 32 characters, but a salt can be used to make the length consistent with another encryption type etc. here's an example of generating a salted hash, it's still just using md5, but it's a much better implementation.