Home / Knowledge hub / Session regeneration
Knowledge hub
Session regeneration
Issuing a new session id at sign-in so an old one cannot be reused.
What it means
Session regeneration means the server throws away the old session id and issues a new one at key moments, above all when someone signs in. Any data in the session carries over, but the identifier that points to it changes.
The point is that the id which existed before sign-in is worthless afterwards. Whatever an outsider knew or planted before the user authenticated no longer opens anything, which is why it is a standard answer to fixation and a core part of good session management.
Why it matters
Without it, session fixation works. An attacker gets a victim to use a session id the attacker already knows, then waits for the victim to sign in. The same id is now an authenticated session, and the attacker is in without ever seeing a password.
It is a cheap control with a high payoff, and it is easy to forget when a team writes its own sign-in code or swaps a framework. An audit question on session handling often lands exactly here.
How it shows up
Most mature frameworks do it for you on sign-in, but not always on every event. Call it again after privilege changes, role switches, password changes and the step-up of a second factor. In PHP it is session_regenerate_id(), in Java servlets changeSessionId().
The mistakes repeat. Regenerating before the credentials are checked, not after. Keeping the old id valid for a while. Regenerating the id but not the CSRF token. Skipping the step in single sign-on callbacks. Compare the cookie before and after sign-in; it should differ. Related reading: session hijacking.
Questions people ask
Session regeneration, answered
When should the session id change?
At sign-in at least. Also after any privilege change, such as an admin elevating, and after changing a password or completing MFA.
OWASP's session management guidance says to renew the id after any privilege-level change.
Is session regeneration the same as session timeout?
No. Timeout ends a session after inactivity or a set time. Regeneration swaps the id of a live session for a new one.
You normally want both, along with proper logout.
Does regeneration stop session hijacking?
It stops fixation, where the id is known before sign-in. It does not stop hijacking by theft of an id after sign-in.
For that you need Secure and HttpOnly cookies, HTTPS and short lifetimes.
What happens to the old session id?
It must be invalidated on the server straight away. If the old id still works, the benefit is lost.
Some apps leave a grace period for parallel requests; keep it very short or avoid it.
How do we test it?
Note the session cookie before signing in, sign in, then compare. The value should change, and the old one should be rejected.
A pentest will also try this across sign-in variants such as SSO and password reset.
Sources
Where this comes from
Related
Terms that sit next to this one
Session fixation
An attacker sets your session id before login, then waits for it to work.
Session management
How your app creates, tracks, renews and ends a signed-in visit.
Session hijacking
Stealing the token that tells your application a browser is logged in.
Logout invalidation
Making sure signing out really kills the session on the server, not just in the browser.
Session token
A random value the browser sends to show it belongs to a signed-in visit.
Does the id change at sign-in?
Session handling that keeps an old id alive after sign-in, or fails to renew it after a privilege change, is something we test on the running app and prove with a request. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.