0

I've a question regarding a forgotten password flow. Basically I'm sending the password reset token out-of-band to the user, and then the user sends it back with the first request via querystring, I validate it and check it's expiry and then I delete it, and generate and store (hashed) a new one which I return to the user with the new password/confirm password UI, where he'll input the new password. (of course, I also delete the second token after the password is changed)

And I'm curious if it's too excessive to generate a new token to send back with the UI. Or should I just send the old one back again, and then check again when it's sent back with the new password.

Thanks, and have a good one.

Improve this question
2
  • 2
    What added security are you trying to achieve with the second token?
    – Neil Smithline
    Nov 17, 2015 at 15:47
  • Just out of principle I guess. Not wanting to reuse the same token again, for the actual change of password http request. But as @TTT said, if one could get sniffed the other could also, since their in so close proxity of each other.
    – danutz_plusplus
    Nov 18, 2015 at 6:59

1 Answer 1

Reset to default
1

I don't see any benefit of using the 2nd temporary token. I assume you're doing this in case the first token is sniffed out during transit, but if it is, then the 2nd key could be sniffed as well. Besides, this process should be occurring within SSL, so the likelihood of getting sniffed is extremely low to begin with.

Typically the weak link in the password reset process is the receiving of an email, but if the user's email account is compromised then the whole process breaks down anyway.

Improve this answer
1
  • Yeah, I had a feeling it was excessive to issue a second one. But wanted to get some other opinions on it. Thanks.
    – danutz_plusplus
    Nov 18, 2015 at 6:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .