Actual password recovery is not a good idea: it means you have to store the password in a form that you can send it to the user.
A better idea is to reset the password to a random value, and email that to the user. He can then change it to something he will remember when he logs in.
There are some notes on passwords here:
Password Storage: How to do it.[
^]
And a generic email routine here:
Sending an Email in C# with or without attachments: generic routine.[
^]
"But we can obfuscate our code and store secret key not in code.
And if user want to recovery (exactly recovery) his password and not to create new why we shouldn't encrypt it?
I really agree with your opinion by in large, but I often see databases with encrypded passwords, not hashed."
"we can obfuscate our code" - oh, that is a good one! "I'll secure my house by hiding the key under the mat, no-one will look there!"
Even if your code is obfuscated, you can still read it. Execute it. Decrypt passwords with it. How many different passwords do you use? Most people (if given a choice) use the same password for everything. Think about it. That means that if your site is vulnerable, then the password to everything is revealed.
"And if user want to recovery (exactly recovery) his password and not to create new why we shouldn't encrypt it?"
Recovery is something I argue against: if the user has lost his password, how do you know it is the user you are talking to when you give it back to him? If it isn't the real user, you have just given out his password and he doesn't know. If you reset his password, and send the new one to the email he originally registered with, then at least there is some margin of security, and the old password no longer works: at least the real user becomes aware that there has been a breach.
"I often see databases with encrypded passwords"
Just because one idiot drives the wrong way up the motorway, does that make it a good idea?
There are too many people out there who do not think before they construct a site, particularly about the security implications. That doesn't mean we should all concatenate our SQL queries, because "lots of other sites are vulnerable to SQL Injection attacks, so we should be too."