0

I have a question. I'm implementing a password recovery, then I thought: "What if a 'stranger' makes an unauthorized password recovery, changing someone's else password?" So, my first decision is: I'll set two fields in the 'user' table, called 'password' and 'temp_password'. If the real user asks for a password recovery, the new random password will be stored in 'temp_password' and an e-mail will be sent. In this way, a spiteful user won't change anyone else password and the e-mail owner can deny the password change attempt. Is that right? Thank you in advance for your help. Greetings

akeeron
  • 15
  • 2
  • Yep. That's a good approach. See here for more info: http://stackoverflow.com/questions/4763719/php-password-recovery – General_Twyckenham Aug 07 '14 at 18:35
  • Why not just generate the random password and replace the password when the user confirms via email? That way you don't need two fields, you just need the password field alone. – Dave Chen Aug 07 '14 at 18:37
  • Also, you generally want passwords to have history (ie, to be able to disallow previously used passwords for that user), which means you often want a separate _table_ for passwords... at which point old passwords don't go away anyways. – Clockwork-Muse Aug 08 '14 at 13:05
  • You should not generate or email a new password - only a temporary token that will allow the user to reset their password themselves. You can email this with the knowledge that if anyone finds it at a later date it won't be useable. Once they follow the link they will be able to update the password - this will protect against anyone else resetting the password of another user. – SilverlightFox Aug 08 '14 at 13:44

1 Answers1

0

I would suggest you normalize this by storing the temp password in a separate table from your user table. Each user will most likely have multiple password recovery attempts during their lifetime and you'll want to store a record of each of those attempts for posterity.

If you keep the field in the user table, each subsequent request after the first password recovery request will override the previous one.

Make sure you have a column in this new table that indicates which request is currently active and have server side / database scripts that ensure only one row per user ID can have an active flag.

Lloyd Banks
  • 35,740
  • 58
  • 156
  • 248
  • +1 This approach is easily to expire the validity of the temporary password . – VMai Aug 07 '14 at 18:45
  • Right, I didn't think about that. I'll use another table! Thanks! – akeeron Aug 07 '14 at 18:48
  • You shouldn't really be storing a password - just a temporary reset token. This does not need to be a separate table as the reset via email can use the same value of multiple requests are sent in the same period. – SilverlightFox Aug 08 '14 at 13:46
  • @SilverlightFox You could store a token, but you definitely should have a separate table to track reset requests – Lloyd Banks Aug 08 '14 at 15:59
  • I can't see why you'd need it - why would you have multiple password resets for the same user? Concurrent ones can use the same token. – SilverlightFox Aug 08 '14 at 16:01
  • @SilverlightFox You would only have one active one at any one time. But for security purposes, you should keep a list of all past requests. If an account has been hit with 200 reset requests in a day's time, there should be a flag that is set off – Lloyd Banks Aug 08 '14 at 16:03
  • Agreed but that would be a separate table for auditing. The actual reset mechanism does not need to get involved with that - it can use the current token to determine whether the token is valid or not. – SilverlightFox Aug 08 '14 at 16:05