If you don't mind having to reset the password instead of giving the old one when a user forgets what their password is, here is what you can do:

p = plaintext password
salt = random value at least 32 bits in size
hash() = cryptographic hash function
c = hash( salt + hash( salt + p ) )
[download]

Store c and salt in the database. When you want to authenticate, take the salt from the database and the password you got from the user, run it through the same function above (hash( salt + hash( salt + p ) )), and compare it to the value of c in the database. If they're equal, the authenticationis successful.

This makes it cryptographically impossible (read: extremely difficult) for anyone with access to the database to know what the orginal password is (this is also why you have to reset the password when the user forgets).

SHA256 or SHA512 are good hashes to pick for now, though recent findings suggest that they're not as good as we thought they were. We don't have any good alternatives right now, and they'll be fine for the forseeable future. Avoid MD5 like it was Microsoft's Paperclip.

When designing the database, I suggest making the column a variable-length text field (like TEXT under PostgreSQL) with no hard limit on the length and put in some kind of text encoding (like base64). You may also want to store what algorithm was used to hash the password. That way, when we finally do have an alternative to SHA, you can switch over with no changes to the database.