Opinion - User passwords should be hashed instead of encrypted. [I didn't see a forum specifically for authentication; if this should be entered in a different forum, please let me know.]

The notes for "DotNetNuke 3.3 / 4.1 Release Status" at http://www.dotnetnuke.com/Community/Blogs/tabid/825/EntryID/420/Default.aspx include the following item:
- Hashed Passwords - hashed passwords are supported through the Microsoft Membership Provider. We should provide a mechanism to support hashed password in DNN as they are much more secure then encrypted passwords and do not rely on MachineKeys. ( It would be advantageous to make this the default but the side effect would be that we would no longer have a password retrieval mechanism )

Obviously, user's passwords should NOT be stored in plain text in the database (or anywhere else), although I have seen too many applications and web sites that do store passwords in plain text. Encrypting the password is a minimum good practice, however storing the hash of the password (and preferably a salted hash) is the best and recommended practice, and should be the default and perhaps only option, in my opinion.

Since a hashed password is not reversible, users cannot be emailed a forgotten password and therefore a different mechanism is required to enable users to obtain access again after forgetting their password. This mechanism should not involve human intervention (such as calling or sending email to an admin person) since this is open to social engineering attacks as well as being inconvenient.

My personal recommendation for storing passwords and recovering from forgotten passwords (for any application, not just DNN) is as follows:
(a) When a password is initially created or later modified, the hash (using a hash algorithm such as MD5) of the password is stored in the database; preferably this would be a hashed AND salted value that is stored.
(b) When the user attempts to login by entering a username and password, the password entered by the user is hashed (and salted if required) and compared to the hashed value stored in the database for the entered username. (If there is not a match, the error message should not indicate in any way whether the username was correct since this helps attackers attempting to guess usernames; it should only indicate that the login was unsuccessful).
(c) If the user forgets the password, the option to recover from this should be to generate a new random strong password and email this to the user's email account of record. Optionally, but preferable in my opinion, this new password (hashed) should be stored in a second field in the database table (not overwriting the original password) and a flag set in the table to indicate that a second password has been set for the user; this allows for the case where the user subsequently remembers the password. When the user attempts to log in in this case, either password (the original or the new generated password) should be accepted, and if either is successful, the flag for the second password should be cleared, the second password should be cleared, and the user should be required to create a new password. Optionally, but again recommended, if the temporary generated password is used to gain access, the user should also be asked for a second item of identifying information that's available in the user table (such as full name or one of the address items if those are required in the particular installation/portal).