how do you store user's password?

[Joshua Cloch]

Hey guys,

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.

Thanks very much.

[Christophe Verré]

You don't retrieve it at all What you usually do is encrypt the password entered by the user, and compare it to the already encrypted one in the database. Using the same algorithm, they should match.

[Joshua Cloch]

Thanks Satou. I know what you mean. However, we usually use one-way function to process password,which leads to "infeasibility" to reveal the origin of the password.

Is there any idea for the user to know his/her password which is in use?

[ankur rathi]

Why not to use opposite algorithm (decryption) to retrieve original password.

[Cameron Wallace McKenzie]

You'll find that in many applications, once the password is in the system,it can't be retrieved. The very reason is the inability to reverse the encryption.

[Bear Bibeault]

Originally posted by rathi ji:
Why not to use opposite algorithm (decryption) to retrieve original password.

The whole point of a one-way hash is that there is no opposite algorithm.

[Adeel Ansari]

Originally posted by Joshua Cloch:
Is there any idea for the user to know his/her password which is in use?

A classis secret question/answer mechanism. Let the user recall his/her password.

[ankur rathi]

Originally posted by Adeel Ansari:


A classis secret question/answer mechanism. Let the user recall his/her password.

Still, the question remains the same. How to get back the original password from encrypted one?

If this is the case, then why people are using one way algorithms???

[Bear Bibeault]

Originally posted by rathi ji:

If this is the case, then why people are using one way algorithms???

A little matter called security.

[ankur rathi]

Originally posted by Bear Bibeault:


A little matter called security.

Okay now I understood, decryption algorithm doesn't even exist so no body can retrieve the original password at all.

Thanks Bear.

[Rusty Smythe]

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.