Don'ts

Don'ts

Whys

For obvious reasons, putting raw passwords means that the DBA or anyone who has access to the database can steal the passwords. If your DB gets hacked into, you'll also expose all the passwords
Encoded passwords are trivial to crack and feed into decoding scripts. Not secure!
Hashed passwords are better than the other two because it's a one-way street for input data, but what if someone already had a list of hashed passwords for the most commonly used passwords? (Hint: it's already exists somewhere on the web)
- Another key thing is that your typical hash (MD5, SHA-256) is incredibly fast to execute, because their purpose is to verify file hash checksum integrities. This is NOT what you want; hackers can just try all variants of fast hashes and attempt to find your password through brute force, even if hashes are not reversible!

Do's

Do's

Add salt, a randomly generated ID for each user, to your hashing function
Use pepper, a randomly generated ID for the application or environment which is shared across all users, to your hashing function
Hash more than once! Add extra iterations
Don't reinvent the wheel; use something like bcrypt

Whys

Two different IDs can hash to the same output possibly. If you add salt to the two different IDs before you hash them, then you'll have two different outputs
- Salt adds another layer of complexity because hackers won't be able to get by with just the hashing algorithm anymore; they also need your Salt to crack the password
Pepper adds yet another variable on top of Salt to make things harder to crack
You can re-hash the same input over and over, which adds some extra processing time in the milliseconds for one password. For hackers, this processing time is multiplied by millions (or however many passwords there are), meaning it takes much more time to crack.
There are libraries that handle all this stuff for you, so consider using them instead of creating one from scratch