Generally speaking, we seldom store the user's password directly in the database. Sometimes, we process the password with cryptographic algorithm and store the result in database. A problem is how I can retrieve the password.
Or, if you have better strategy in this password storage problem, please tell me.
By allowing the user to retrieve her password, you are introducting a security hole in the system.
This same method will allow an attacker to retrieve a password. As Satou stated, a common way to store passwords is to hash (encrypt) them and then store the result in the database.
I'm assuming that you want the user to be able to retrieve her password in the event that she forgets it. If this is not the case, please state [bold]why[/bold] you need to be able to retrieve the password, so we can help you better.
If the user forgets his password, then you will want a method to allow them to reset their password. Ask youself the following questions: 1) Should the user be able to reset her own password without assistance from someone else? 2) How do we prove the person requesting the password reset is really the account owner? 3) Do we need to track password reset requests for attack analysis? 4) Do we need to restrict the number of password resets per (hour/day/week/ever)? If someone can't get their password re-re-set, what impact will that have?
The answer to those questions will influence the approach you will take.
On one site I wrote for a client, they wanted their users to be able to reset their own passowords without assistance and they used the criteria of email address to establish identity. Only the last password reset request was to be tracked, and there was no restriction on resets. They also wanted to only allow a short window during which the password reset would be active, and they wanted to prevent disruption of service (if an attacker requested a password, the original user should not be affected).
The solution I provided allowed a "temp" password with a timeout value. When the user clicked on "forgot password," he was prompted to enter his email address. If the email address matches a user-record on file, then a temp password was generated and set to expire within 10 minutes. (If there is no match, no indication is given to the user of this fact, to prevent email address phishing). The user can either log in using his original password (if he remembers) or his temp (if it hasn't expired yet). Once logged in, he can reset his password.