Using MD5 would work. Store the MD5 hash of the password in the database. When a user logs in and gives their username and password, take the MD5 hash of the password that they submitted and compare it to the stored value. And since only the MD5 hash is in the database, someone who gains access to the database still won't be able to figure out the passwords unless they feel like brute-forcing it.
Storing MD5'd passwords makes things a smidgen less convenient in that there's no password recovery feature. One solution is to offer a password reset feature. Dyndns.org uses this, and I think slashdot does as well. When someone asks for their password to be reset the server creates a new password and emails it to the email address with which the account was registered. The original password continues to work, so that someone can't lock someone else out of their account by requesting a password reset. The old password only stops working when someone successfully logs in with the new password.
Slashdot Mirror
Using MD5 would work. Store the MD5 hash of the password in the database. When a user logs in and gives their username and password, take the MD5 hash of the password that they submitted and compare it to the stored value. And since only the MD5 hash is in the database, someone who gains access to the database still won't be able to figure out the passwords unless they feel like brute-forcing it. Storing MD5'd passwords makes things a smidgen less convenient in that there's no password recovery feature. One solution is to offer a password reset feature. Dyndns.org uses this, and I think slashdot does as well. When someone asks for their password to be reset the server creates a new password and emails it to the email address with which the account was registered. The original password continues to work, so that someone can't lock someone else out of their account by requesting a password reset. The old password only stops working when someone successfully logs in with the new password.