Here’s a quick rundown of some of the common ways to store a password in a database, and a few considerations:
If you store your passwords in cleartext, you probably should find someone else to do the coding for your projects. I won’t go into the risks – you’ll find them out soon enough.
Running the passwords through a hashing function such as MD5, SHA-1, or SHA-256 will create one-way hashed representations of the original password.
The danger here is precomputed rainbow tables – you take a dictionary or all the combinations of letters and numbers up to a certain length and hash each word to check against later.
This has already been done for most combos of letters, and is freely available (and even indexed by Google – check out the funny and somewhat scary BozoCrack project).
Hashed (salted well)
You can make the stored hashes less likely to be looked up by salting the hashes by appending a string to the term that is going to be hashed. You’ll need to store the salt somewhere so you can re-append when checking against this value at a later time. This makes the hash for a particular word different than it would have been by itself, and less prone to automated lookup.
Be sure to use a long and randomized salt when you do this, as it is trivial to compute lookup tables for given salt values, and for most shorter or simple salts, tables have already been generated.
Hashed (salted well and uniquely)
You can drastically improve the security of your stored hashes by simply using a long, randomized, and unique salt for each row, rather than one salt for the entire database.
Doing this would require the generation of lookup tables for each hashed password in your database, rather than creating just one lookup table that would be applicable to the entire database.
Hashed (salted well and uniquely) + key stretching
Using a method such as PBKDF2, you can add an additional complicating factor: time.
By adding an iteration count to your hashing method, rather than running the hash once, you run it potentially thousands of times, with the result of each previous run feeding the next. The idea is to increase the amount of time to generate a hash to something unnoticeable to a human, say half a second to a whole second to generate the hash, but expensive timewise to repeat many times.
By doing this, you dramatically increase the time it would take to create a lookup table for a particular salt. You can also keep abreast of Moore’s Law by increasing your iteration count every few years and rehashing.