I'm doing a module which allow users to reset password. I noticed how most websites they provide a confirmation link which contain query string that has a unique hash.
My question is: How can I generate this unique hash each time the same user request forgot password? Should I store this hash in database and use it for verification later on? Will it be safe? Or should I create some sort of algorithm which generate one-time password? How can I generate a OTP?
Yes, you should
There seems to be a lot a confusion about the generation of the reset password (or whatever you want to call it). Please read the answer I've linked to and don't reinvent the wheel with hashes and weak seeds.
1) To generate the unique hash, mix current-time, user-id and some salt (text). For example, if your website is mysite.com, then use this code:
$hash = md5(time() . $userid . 'mysite');
This will create a nice hash.
2) Yes, store it in database.
3) Yes, as long as you expire the hash after a fixed period of time, it will be secure.
4) No, generating one-time password usually annoys users.
Just using some hash function with user's ID, user's salt (you salt the user's password, right?) and pseudo-random data should be OK:
$pwd_reset_hash = hash ( 'sha256' , $user_id . $user_salt, uniqid("",true));
Store it in the DB (together with time of request) as the reset key for this user
user_id pwd_reset_hash time_requested
===========================================
123 ae12a45232... 2010-08-24 18:05
When the user tries to use it, check that the hash matches the user and that the time is recent (e.g. "reset code is valid for 3 hours" or something like that)
delete it from DB when used or expired
The way to go is indeed generate some kind of random thing and storing it in the database. As soon as the password is changed you remove the relevant record from the table so that the link cant be used again.
As said already in the other responses, doing a SHA1 or an MD5 of the userid, combined with microtime and some salt string is usually a safe bet.
On relatively easy way is to use an encryption algorithm in counter mode. You keep a secret password, and a counter (the latter typically stored in the database). Each time you need a secret hash, you increment the counter, encrypt it with your password, and convert to text with something like Base64 encoding.
Unlike most of the others that have been mentioned, this one makes it pretty easy to keep track of where things can break down. Basically, there are two possibilities: 1) the encryption algorithm you're using gets broken, or 2) somebody gets to your secret password.
If you use a well-known, widely-used algorithm like AES, the first is a pretty minor concern. If somebody breaks it, they're going to be too busy grabbing a few billion from every bank on the planet to bother with your web site (unless there's some possibility of the web site in question dealing in so much money that they're going to bother with it). For most practical purposes, that leaves only one thing for you need to deal with: ensuring that your secret password stays secret.
That's pretty easy to handle. It's hard to keep things like credit card numbers secret because you need to make them available to the right people under the right circumstances. This is much easier, for the simple reason that there's never any reason to give it out to anybody.