Require Same Session ID Through All Password Reset Process Steps

Question

Our password reset logic works as follows:

1. user clicks "forgot my password" and enters the email address of the account
2. email is sent with a cryptographically secure token, and the email address of the account for which the pw needs to be reset.
3. user clicks the link, and if the token matches, they see a box to enter a new password.

I read that we should require the sessionId to match all throughout this process.

Is that a feasible thing to require? Are there any "normal use cases" where requiring the same session id would not work? Might IP address be a more appropriate e.g. to get around the below issue:

e.g. first two steps done in browser A, but when they click the link in the email, it opens browser B, thus, new session id.

Answer 1

EDIT - Two answers below.

Original Answer

You could embed another ID in the link which tracks back to the original Session ID.

Is the requirement that the email link, when clicked launches in the same browser or can it be on a different browser? What if it's on a different machine? For example, what if I reset the password from my phone, then move over to my computer or tablet, click on the link in the email and set up a new password? I might do this if I want to use the password store on my computer even though I started on my phone. From an ease of use perspective, it seems that the password link in the email and not the session ID from the original browser is important.

Furthermore, if the "Forgot Password" link was clicked by an attacker trying to gain entry and you force the Session ID to be the same, then the real user who receives the reset password link might experience a DOS depending upon how your system works. Certainly, the legitimate user can't reset her own password with the link provided because the Session ID originating the "Forgot Password" request resides in the attackers browser.

As application developer, you should be able to do one of the following:

1. Recognize a second session started from the password reset link as legitimate and let it go through.
2. Process the reset link and set it back to the first session ID.

However, I really think #2 is ill-advised given that an attacker might be clicking on the Forgot Password Link. I think your best bet is to use the second session.

Incidentally, the most paranoid systems I've seen force a re-login once the password has been reset. That is, you click "Forgot Password", get the email, click on the link, reset the password, then you're presented with a fresh login page which requires you to enter your username and new password (instead of quietly being logged in as a consequence of the password reset).

Second Answer - clarification in Question Comments

It looks like you're concerned with the OWASP article referenced. In this case, the article recommends doing one continuous session for a password reset and use an Alternate or Out Of Band (OOB) Channel to increase the likelihood you're speaking with the legitimate user. In this case, the user initiates the password reset process, answers security questions correctly, is locked out of the account, an OOB PIN code is sent via SMS or email (note, not a reset link), user enters correct PIN code, then new password may be entered.

This wasn't what the original question contained. In this case, a password reset link is not to be sent and only a PIN code to be viewed with an email reader and entered in the same password reset session flow. Jumping to a new Session ID (even if possible) ought to be seen as an attack or system bug and rejected.

Answer 2

I really have to disagree with the other answers, when answering the question as asked.

First, let's assume the attacker knows your email address, and has a way of reading a reset email sent to you.

If the attacker can read the email sent to you, he almost certainly knows what your email address is. You also said that all he needs to generate the password reset email is your email (which we just said he has.)

This means that either:

• He can't read your email, so your password reset token is safe from him (So you don't need it to be the same session)
• He can read your email, and therefore probably knows your address. This means he can easily click on the password reset link himself and generate a new password.

Now there are corner cases:

• The attacker thinks the second email might reveal to the account owner that the account is compromised, and he can't delete email from the inbox
• The attacker can somehow read the email without actually knowing your email address

Generally though, I think those cases are pretty unlikely, and much less important than the usability problem. Here are three examples:

• I'm browsing on my tablet, but forget my password. I click "Forgot Password" and then use the email on my desktop. Now your password recovery failed. I hope you have a really good error message, or I'll think your site is broken.
• I'm browsing in Chrome, and click "Forgot Password". I alt-tab to another browser where I'm logged into the other email account this account is tied to. I click the reset link, and again it failed.
• I'm in a private tab and click Forgot Password. I see the message in my mail client, and click on the link, opening the link with the system default browser. Again, failure.

I think that the UX problems are much more important than any very small security improvements you would gain by requiring this.

Where this might be more useful is if "Forgot Password" requires more than an email. If you sending the reset email requires answering a security question, then this might actually be useful. Otherwise it's probably just annoying.

Answer 3

As with most OWASP articles, the reasoning behind some of the suggested implementation steps are not always explained, leaving readers to guess what the advantages and risks are of not taking into account every recommendation. Some of them can be safely ignored, while others are critical to mitigating the original risk. I would suggest you always use OWASP as a good starting point and then try and figure out whether the whole solution is actually required (as you've already done).

Is that a feasible thing to require? Are there any "normal use cases" where requiring the same session id would not work?

Ignoring the implementation in the OWASP article and speaking generally about password reset mechanisms, the requirement to only allow resets from the same session prevents a password reset token sent by email from being intercepted and used by an email eavesdropper. Say that an attacker had setup a mail forwarding rule so they get a copy of every email sent to an account. Note that this only really applies if it is in combination with security questions (which have their own problems). Otherwise an attacker could just request the reset directly then follow the link from their own session.

This would also work for SMS reset tokens, where an attacker had managed to get malware onto the victim's phone to read messages, or had managed to clone their SIM to receive SMSs addressed to the victim.

It would not work for some out-of-bound password reset mechanisms, such as sending a reset token via snail mail unless this session identifier is persisted for an extended length of time (this could safely be accomplished via an additional cookie token, not related to the actual logged in session).

At the end of the day, the decision to use such a mechanism depends on the risk appetite of your site and its "security level". In essence it is requiring the exact same browser to be used in order to complete the password reset process (discounting session fixation or session stealing attacks). It does have limitations such as not allowing a reset roken activated from a mobile browser from being actioned on a PC. In that case the restriction could be relaxed to require the same IP, however this offers no protection when the attacker is on the same network, or in the case where shared ISP proxies are in use (e.g. AOL, 3/4G providers).