[RESOLVED] Lost password strategies

robkir

I'm trying to think of a good strategy to let strangers who have registered with my database, but lost their username and or passwords, to be able to reset their own password.

I am thinking of:

Having a php page that says "lost your password" with an input field for the user's email address.
Upon submit, an email is sent to the user containing the user's user name and a link to a Password Reset page on the server
The user clicks on the hyperlink and goes to the Password Reset page where he/she again puts in his/her email address and his/her user name and assuming those are correct, the user gets to reset their password.

I'd like some opinions...is this method secure enough or am I inviting problems? Any other ideas how I should handle this?

Thanks

halojoy

Most common, as what I know, is upon click lost password
- generate a new temporary password for user with email=xxx@xxx in database
- send an email with the new password
- the user login with new password and can change it to what he wants

This is of course on sites where register by Email confirmation.
And there is probably no other better simple method to verify a person,
than by email confirmation and activation.

robkir

Hi Halojoy,

That's what I thought. I suppose someone could spoof an email address to gain control of one of the user's accounts, but that would entail them knowing the user's email and it won't be published on the web, except for the user and, of course, me.

thanks for the reassurance.

robkir

Paavero

Wouldn't any user be able to reset another user's password using halojoy's method? Sure, the user would get an email about it, but it opens up the possibility to terrorize others.

You'll probably want to generate a random token that is stored somewhere and then emailed to the user's inbox in the form of a link. The password would then be reset by clicking the link in the email. After the password is reset, the system would send another email with the new randomly generated password and a message to change the password.

robkir

Hi Paavero,

I worried about that very issue; however, when a user logs in they need both a User Name and a Password. Perhaps the user that asks for the password reset might be at risk if his email was spoofed, but even if a nefarious web hacker goes to the password change page, he won't be able to do anything to other users without knowing any other user's User Name. At least, that's what I hope happens.

I am open to your idea of a randomized token but confess I haven't a clue how to set it up. Can you point me towards a web page that could explain the concept to me.

Thanks for your input.

robkir

laserlight

The problem lies in how you interpret "new temporary password". If this generated password overwrites the existing password, then indeed it makes the system vulnerable to a situation where anyone is able to change anyone else's password, even if they never know what the password was changed to.

On the other hand, if this generated password does not overwrite the existing password, then it becomes equivalent to the random token that Paavero had in mind.

robkir

Interesting suggestion, laserlight, but how would one generate a new password that would allow the user to update their own password, without over writing the original password? These kinds of coding are intriguing learning opportunities. The problem is trying to get one's mind filled with enough understanding that the mere description of the activity is enough to get the programmer started. Sadly...my brain isn't filled with enough knowledge to take your idea and run...if you have time I'd appreciate a bit more info on the nuts and bolts side -- or an example would be most welcome.

Thanks,
robkir

laserlight

You just need to store two passwords, and allow the user in if either of the passwords match. (Of course, you would actually store cryptographic hashes of the passwords rather than the passwords themselves, but it's the same idea.)

Separating this secondary password into a separate random token involves slightly more work, but may be better in that the password reset mechanism is not so closely tied to the normal authentication mechanism.

robkir

I found an article on the internet that explains how to make a randomized token and decode it--that was the part of the puzzle I didn't understand. Question for you: why bother with two passwords? If the user can't get in with his/her original password, is it really necessary to keep his/her old password alive?

laserlight

robkir wrote:
If the user can't get in with his/her original password, is it really necessary to keep his/her old password alive?

It is not necessary to maintain the existing password, but it is good practice to do so.

Imagine if I sold you this high tech electronic physical lock. At my shop, I help you to configure the lock such that whenever a special button on the lock is pressed, the lock generates a new random number combination that is eventually sent by text message to your mobile phone. You can then use this number combination to open the lock.

So, you happily use this feature, lock up your locker, and go on your way. Later in the day, you come back to your locker, try the number combination, but lo, the lock does not open! Maybe you used the wrong number combination, so you try different ones, but all do not work.

Finally, in frustration, you pull out your mobile phone to call me, and see that you have received a dozen text messages, but you did not notice because your phone was on silent mode. It turns out that passers-by have been pressing that cute little button on your lock, thus resetting the number combination each time.

This is like what can happen if you directly change the user's password in response to a request for a password reset, before you have verified that the user is who he says he is. This verification can be done by using a random token provided to a special password reset page that only resets if the correct (single use) random token is provided, or it can be done by using a temporary secondary password.

robkir

Excellent analogy, Laserlight and it makes sense, too.

Thanks. I'll modify my code.

sois

laserlight;10940158 wrote:
It is not necessary to maintain the existing password, but it is good practice to do so.

Imagine if I sold you this high tech electronic physical lock. At my shop, I help you to configure the lock such that whenever a special button on the lock is pressed, the lock generates a new random number combination that is eventually sent by text message to your mobile phone. You can then use this number combination to open the lock.

So, you happily use this feature, lock up your locker, and go on your way. Later in the day, you come back to your locker, try the number combination, but lo, the lock does not open! Maybe you used the wrong number combination, so you try different ones, but all do not work.

Finally, in frustration, you pull out your mobile phone to call me, and see that you have received a dozen text messages, but you did not notice because your phone was on silent mode. It turns out that passers-by have been pressing that cute little button on your lock, thus resetting the number combination each time.

This is like what can happen if you directly change the user's password in response to a request for a password reset, before you have verified that the user is who he says he is. This verification can be done by using a random token provided to a special password reset page that only resets if the correct (single use) random token is provided, or it can be done by using a temporary secondary password.

Great post! Well, I'm glad I've done something right on my page, I use this concept on my "forgot password/username" scripts.