So I understand the purpose of regenerating a session ID after a state change such as authenticating, i.e to prevent session fixation. What I'm not clear on is why this would be necessary after a password change (as recommended by OWASP).

If an attacker has hijacked the victim's session cookie, yes, invalidating that sessionID would kick the attacker off, but why should that be done specifically at the time of a password change? Is it because there is an assumption that if a user is changing their password, that they may suspect their account has been compromised? Otherwise, a password change seems like an arbitrary time to regenerate the sessionID.

In the case of an attacker who has stolen the victim's password: the attacker will have his own session. Regenerating the sessionID after password change would not affect the attacker's session, would it? (On that note -- is the current best practice to invalidate ALL sessions after a password change? I seem to be getting varying answers on this.)

5 Answers 5


Is it because there is an assumption that if a user is changing their password, that they may suspect their account has been compromised?

Somewhat. It's very standard advice to tell anybody whose account looks possibly-compromised "hey, change your password". It's not like updating the session token is that expensive anyhow, so this is a pretty high-value time to do it. The cost is low (even if there's no account compromise even suspected, it's no harder than the user logging in again normally) and the potential upside is a lot.

is the current best practice to invalidate ALL sessions after a password change?

Like so many things in authentication (session length, additional token restrictions, credential types and restrictions, authentication factors, delegation, least-privileged access, etc.), this comes down to a question of use case, sensitivity of the app, and security vs. convenience. My personal take is that you should offer the user the opportunity to revoke all extant sessions:

"Password change successful! Would you like to log out all other sessions? You should select yes if you're worried that somebody else may have used your password. If you select yes, you will have to log in again on any other devices you use."

The best approach is to actually show the user a list of other sessions, and let them revoke them all or only certain ones. In fact, you should have such functionality available even if the user hasn't just reset their password (see e.g. https://myaccount.google.com/device-activity.) However, if you don't have any of that - no list of active sessions for individual revocation, nor UI that asks "do you want to revoke all other sessions?" - then you probably should end all other sessions automatically. This may not always align with user expectations, but in the worst case they just have to log in again a few times unexpectedly, and in the best case they have kicked an attacker out of their account (hopefully before much damage was done).

In the case of an attacker who has stolen the victim's password: the attacker will have his own session.

This is true (or at least, should be assumed true). However, even in such a case, the advice "change your password" may still be relevant even if other sessions aren't revoked... if there are short and enforced session lifetimes. By preventing the attacker from logging in again, the user has mitigated the lost password. As such, if session lifetimes are short and enforced (max lifetimes, after which there is no way to continue accessing the service except fully logging in again), then you arguably don't need to reset other sessions when the user changes/resets their password; there probably aren't any other active sessions anyhow (because they expire so fast) and if there are, they'll end soon. I'm talking about really short sessions here, like just a few minutes, hard limit.

In all other cases, having a way to force session revocation is good. In particular, if you're using JWTs with refresh tokens, the lifetime of the JWT of course needs to be very short (single-digit minutes, usually), and password changes should (at least offer to) rotate your refresh token and revoke all the other refresh tokens (since you can't really revoke a JWT, this is the only way to end other login sessions).

If the user did a password reset, rather than a password change, you should probably revoke all sessions anyhow. Resets are more common than (voluntary) changes, so you're more likely to have "false positives" where you revoke sessions even though they're all legitimate, but also an attacker who steals a user's password will very often immediately change the password themselves, and the reset flow may be the only way the legitimate user can get back in. (Of course, if the attacker is able to, a smart one will also change the password reset credential - e.g switching to an email account under their own control - so the user may have no option but to resort to support... who should DEFINITELY revoke all extant sessions if a user reports being locked out of their own account, the user can authenticate themselves to the support operator, and the login credentials have been recently changed).


The idea behind regenerating the session ID on a password change is to ensure that if an attacker already has a valid session when the user changes the password then they don't get to keep that session.

The idea here is that if the attacker has hijacked a user's session then they can perform actions as that user until the session expires.

If the user changes their password during that time then the attacker can still use the hijacked session for up to the session's expiration.

By regenerating the session ID on a password change then the attacker's session is invalidated, meaning they have to create a new session (which will not have the rights of the user) or steal a new session.

The idea is not to invalidate all sessions after a password change, as that would be inconvenient to the user. Instead, only the session the user is currently using is invalidated.

So to answer your questions:

Yes, regenerating the session ID after a password change is necessary to prevent an attacker from using a hijacked session after the user changes their password.

No, regenerating the session ID does not affect the attacker's session, as the attacker is not using the user's session.

No, the current best practice is not to invalidate all sessions after a password change, but just the session the user is currently using.


Regenerating the session ID after a password change is a security measure that helps prevent session hijacking.

If an attacker has stolen the victim's password, they will not be able to access the victim's account without also having the victim's session ID. By regenerating the session ID after a password change, the victim's old session ID becomes invalid, effectively logging out the attacker and preventing them from accessing the victim's account even if they have the victim's password.

It is recommended to invalidate all sessions after a password change to prevent an attacker from accessing the victim's account using any of the victim's old session IDs. This helps to protect against session hijacking, as well as other potential security issues.


Everytime a user's security-related state (authentication and/or authorization) changes, it means that the previous state is invalid.

OWASP's suggestion is to regenerate the session token (ID) with every state change, in order to enforce this concept, and treat each old one as invalid.

Note that changing a session token provides a lot of benefits in the case of client-based sessions where you don't want to hit the db or the auth server with every request, in order to check for state changes. Similar benefits exist for server-side sessions, because it shortens the window of opportunity to use the old session tokens in case of caches being employed. For example, let's suppose that the current state (authentication and authorization) of a user is associated with a given session token and you either have a client-side session (e.g. JWT) with expiration date or a server-side one with caches. Consider the following:

  • some privileges of the user are revoked (authorization change); you don't want the user to use the system with the revoked privileges by keeping the old token
  • the user is granted some privileges (authorization change); having the user using the system with the previous set of privileges is not ideal
  • the user changes her password (either as part of a security practice or because she forgot it and wants to reset it - this is an authentication change); the previous authentication state is no longer valid - you know that only the current state is valid because the user in that state is authenticated (you cannot be sure about anyone in the previous state). Thus, it would be a good idea to associate the new (valid) authentication state with a new session token. Keep in mind that this is especially valuable in the case where the state token is not associated with authentication but only with authorization (e.g. JWT with permission claims); when a password is changed and the token stays the same, then there's a problem in the security of the system if you don't invalidate all current session tokens of the user - or just issue a new one, because a user can use the old token even though they may not know the new password

When it comes to attackers that use the system by employing a stolen session token, changing the token with every state change shortens the window of opportunity of the attacker to abuse the system (although, this also depends on other factors as well; e.g. how often does a state change take place).


Password change workflows create an elevated status

You are right, technically speaking, the password change event itself does not require your application to issue a new session ID.

However, many password change workflows include a step-up authentication step. For example, the end user might be required to enter the old password, or enter an out of band code. When the user can complete these successfully, the user's session receives an elevated level of privilege that allows the user to change the password. It is at that point your application should issue a new session ID. Otherwise, the attacker will also be able to access the elevated status, and potentially be able to change the password too.

You must log in to answer this question.

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