Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
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?
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.
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.
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).
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.
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.
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.
