One school of thought states that the best way to store users' password information is not to store the passwords themselves, but rather hashes of the passwords. When the user first signs up for an account, your application creates a hash of the password and stores that in the database. When the user logs in, your applocation creates a hash of the password entered by the user when logging in and compares it to the hahs of the password stored in the database.
This approach has the advantage of maintaning user privacy; you wouldn't be able to find out what your users' passwords are without a great deal of work. The downside is that you can't email a password reminder should the user forget his or her password (instead, you email them a link leading to a page that lets them define a new password.)
The article How to Encrypt Passwords in the Database covers handling password hashes with source code in PHP and VB.NET/ASP 2.0.
But seriously...
I think the article explains the principles of storing hashes of passwords rather than the passwords themselves pretty well. Yes, neither it nor I didn't cover all the security bases, but that's beyond the purview of an introductory article.
Tell you what -- give me a little time, and I'll write an article that covers those issues you mention in your post. How's that sound?