The OWASP Forgot Password Cheat Sheet suggests:

Whenever a successful password reset occurs, the session should be invalidated and the user redirected to the login page

I'm failing to understand why this is so important. Is there a security basis for this recommendation and if so, what is it?

  • 1
    Maybe it's just a minor point and is not so important, but it does keep the user from entering their details elsewhere...they do crazy stuff like that sometimes
    – Arlix
    Commented Nov 10, 2015 at 14:03
  • 71
    So I can store the new password in my password manager :)
    – Cano64
    Commented Nov 10, 2015 at 17:27
  • 2
    This would depend on the password reset mechanism. A user resetting password because he doesn't remember the password would normally not have a session since he is not logged in. IMO there could be some problem in the way the sentence is worded if "the" session refers to sessions created by other users on the same account. Commented Nov 11, 2015 at 13:28
  • I would have thought this was a UX thing so it's quicker to put the new password in.
    – Pharap
    Commented Nov 12, 2015 at 20:01
  • This is a old question, but I am curious if this is implemented out of box in Identity Apps like Ping Identity, Oracle Access Manager, WSO2 Identity Server, Okta etc.?
    – Saqib Ali
    Commented Feb 15, 2018 at 23:08

9 Answers 9


Lets say an attacker has your password. You log in and reset it. If the reset doesn't invalidate all existing sessions, the attacker still has access, as long as they don't let their session expire.

The reset hasn't actually achieved anything in this scenario.

Depending on what the site does, there could also be issues with having you signed in under a password which is now out of date. Lets say your password is used to unlock something, you are signed in with "password1", but the server now has your password saved as "password2", what happens? This is obviously hypothetical, but hopefully illustrates the point.

Redirecting to the login screen I guess is just a recommendation. I'm not sure why it matters where you send the user, but from a usability point of view it makes more sense to send the user to a login page rather than the home page.

  • 68
    Why send the user to the login screen, instead of ... sending them through the login screen and actually logging them in again? I understand the suggestion to invalidate existing sessions, that sounds sensible, but "I typed my complex new password twice and you still don't know who I am and you immediately want me to type it again" is a very frustrating user experience. Commented Nov 10, 2015 at 18:01
  • 9
    What you write in the first paragraph and what is your first point built upon (...invalidate all existing sessions) is not what is written in the OWASP Cheat Sheet (the session should be invalidated). Commented Nov 11, 2015 at 9:04
  • 7
    The fact that the user logs in doesn't invalidate existing sessions. Commented Nov 11, 2015 at 10:58
  • 7
    As I commented before, all those things you listed can easily be done without going to the login-page. So, stripping everything not answering the question, it boils down to your last paragraph: "No idea, I guess it's a recommendation for usability." Are you sure you cannot find any security-related reason? Or at least elaborate on why that's good usability? Commented Nov 12, 2015 at 4:11
  • 5
    -1 This doesn't really answer the question at all! See @TessellatingHeckler's comment. (only I can't -1 with my rep, sorry).
    – Pavel
    Commented Nov 13, 2015 at 9:19

Protecting sessions on possibly compromised account

There is no need to actually redirect to the login page if session management upon password change is done securely. That is, as long as all current session identifiers are invalidated and the current session is attached to a new session identifier (usually issued as a token in an authentication cookie - the cookie is only sent to the session that just changed the password) then there is no risk of an attacker who is already in the account from staying logged in.

OWASP Article

The rationale behind the OWASP article is explained below. There is nothing wrong with the security aspect of it, however there are some usability issues.

Password reset functionality is often used when a user wishes to secure their account.

By invalidating all existing sessions upon password reset, the system is making sure that only the person with the new password can login.

Say, for example, an attacker that has gained access to the account using the old password is logged in. Resetting all sessions will log the attacker out.

Why log out the current user, I hear you ask?

Well say that the attacker is riding on the current user's session, say using a session fixation vulnerability. This means the attacker has the same session as the real user. Resetting the current session also will make sure no one is on the account who is not meant to have access.

Redirecting to the login page in your quote above is really describing the fact that you should log the user out of the current, and all sessions (but there is no risk from stopping you dropping them into a new session with a new identifier).

  • 8
    How does invalidating current sessions and putting him in a new one neccessitate sending the user to the login page? Commented Nov 11, 2015 at 4:23
  • 2
    I don't think it does as long as long as the current session and all other sessions are invalidated. Creating a new session, with a new session token value for the current client would meet the above security requirements and would subdue an attacker that has either ridden the session or gained the previous password. Commented Nov 11, 2015 at 10:51
  • Because if you just logged them out, they'll want to log back in!
    – komodosp
    Commented Nov 11, 2015 at 13:00

The other answers are probably more correct from a netsec perspective, but I wanted to add that you also get to make sure that the user is actually able to log in with their new password. This makes it obvious if something is going wrong, like the browser autofilling an old password.

It also prevents users from using the password reset as a login. On one of my accounts it's easier to answer the security questions than to remember the password, since I must set a unique password each time I reset it and can't remember them.

  • 7
    Yeah, the "OhNoSecond" where you realize that you mistyped your password while resetting it and now have no idea what it is, is one of the great, breathtaking experiences of IT. Like looking in to your locked car to see the keys on the driver's seat.
    – user82913
    Commented Nov 10, 2015 at 20:00
  • 2
    @nocomprende But if only car doors had email-based reset
    – wavemode
    Commented Nov 12, 2015 at 14:55
  • I have no idea how I'd lock my key in my car; you need the key to lock it!
    – user7146
    Commented Nov 12, 2015 at 17:09
  • 3
    @Alex Easy. Lock the door, put your key in the car, close the door. People do it all the time. Or is there something about your car in particular that prevents this?
    – Ajedi32
    Commented Nov 12, 2015 at 19:45
  • 6
    +1 This actually answers the question (unlike the two more upvoted answers).
    – Pavel
    Commented Nov 13, 2015 at 9:29

There is only one possible security-related reason to send you to the login-page, as all old sessions can be invalidated and your current active session you changed the password from replaced automatically:
It makes using the password-reset for logging in more cumbersome, thus leading to you less often using it, and thus keeping it more secure from eavesdropping and accidental disclosure.

There is also a usability-reason for sending you there: It makes sure you can actually use the new password, and any in-browser password-cache gets updated.


If users are allowed to have the browser store their passwords, redirecting the user to the login page will allow the browser to capture the new password at that page. Otherwise, the next time the user logs in the browser will "helpfully" pre-fill the password field with the old password--an action which is likely to cause confusion if the user doesn't realize what's going on.


It is very simple if we keep in view the security countermeasures. It will actually invalidate all your active sessions, as well as the device of stealer, who created the trouble.

  • And that could not be done in a far more user-friendly manner? I fail to see that, where's the part neccessitating a re-logon? Commented Nov 11, 2015 at 16:06

In addition to providing an easy mechanism for establishing a new valid session, verifying that the new password works, and logging out current sessions, there is also the added benefit of having your user enter the password a 3rd time, making it easier to remember.


In addition to many of the other points made here there are advantages to limiting the session creation mechanism to only one entry point from a maintainability/hardening/audit perspective.

A user resetting their password in the locked-out state should not necessarily be treated as a logged in user even after jumping through whatever recovery proof of identity hoops you have otherwise you have an additional sequence to test around when doing your audit/pen testing.


when you login again straight after a password reset

a) you are more likely to remember the password 3 seconds later, than 3 days later.

b) your browser can then ask the user if they want to update their saved password with the new one, and then the browser will remember it on the login page.

You must log in to answer this question.

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