The webmaster's guide to passwords
Here’s the short summary: if you’re storing user passwords unencrypted anywhere, you’re doing it wrong. If you don’t understand why, you should stick to using free open-source packages like Drupal and not roll your own login system. Also, if you’re not a webmaster, and you ever get an email from a website which provides your unencrypted password, you should know that this site is probably not doing a good job storing your password securely.
The problem is this: sites get hacked, and databases get compromised. Encrypting the connection (your SSL certificate, the https in the address bar, and all that) just protects the customer’s communication with your server. It’s nice that they’ve stopped crackers from harvesting passwords one by one as their users provide them, but what’s the point if a successful compromise of the server means everyone’s passwords are available to the cracker?
The first thing you need to know (if not understand) is that there are certain functions which are one-way; that is, the input cannot be determined by the output. Some of these are called hash functions. If you run a sufficiently strong hash function on a password, it is not possible to determine the password from the hash. (The output of a hash function is sometimes called a hash.) (Hash functions are like padlocks: some are stronger than others. But even a weak lock is better than none at all.)
“But wait,” the inexperienced webmaster says, “how can I tell if my user is providing the correct password when they return to the site?”
Well, think about it. They’ve stored a hash produced by running a hash function on their password. Why not run the same hash function on the password provided at login time and see if the resulting hash is the same as the one in the database? Problem solved.
(N.B. You might also want to read up on “salt.”)