Forgotten password reset page: should the user need to enter a username/email as well?

2
votes

I am re-implementing the "reset password" functionality for the next version of my user management system. The way it works currently is:

  1. The user enters their username and email address.
  2. If this information is correct, a random token is generated and stored in the DB, and a link with the token is sent to the user's email address on file.
  3. The user clicks the link, with the option to either "confirm" or "deny" the reset request.
  4. If they confirm the reset request, they must enter their email address, as well as their new password (and repeat the new password as well). This is POSTed to the server along with the token. If the email address matches the token, and the reset request hasn't yet expired, the password is updated.

My question is: do we really need the user to re-enter their email address when they create the new password? If the random token is sufficiently strong, does requiring this extra piece of information provide any added security, or does it just worsen UX?

1
securityuser-managementforgot-passwordreset-password
Couldn't you just encode the email address in the link that is sent to the user? Then the user wouldn't have to type in anything other than their new password. – Mathew Tinsley
Indeed I could - the question is, should I? – alexw
Requiring the email seems to address the use case where an attacker knows (or can guess) the token, but doesn't know the email address. If the attacker is getting the token from a user's email then the attacker definitely knows the email address. Encoding the email address in the URL that is sent to the user doesn't seem to give an attacker any information they wouldn't have already. You might want to run this by security.se – Mathew Tinsley
If the token is unique, I don't really need to encode the email address at all. I can identify a user solely by their token. – alexw
That's true, but then technically an attacker could change a password if they knew any token even if they didn't know the email address. In practice I don't think this is much of an issue. My overall point was that you could keep the same layer of security (albeit a weak layer) without troubling the user by making them manually type in their email address. – Mathew Tinsley

1 Answers

2
votes

I don't see any value in doing this. Just make your key secure. Perhaps a 128-bit (that's 22 base 64 encoded characters) secure random. That seems large enough. Also add a timeout to the token life span. 24 hours seems a fine compromise between security and inconvenience.

I like the idea of adding the email address to the token so you can log failures more intelligently.