3

The question is related to session-ID management in a particular php-based web-app.

The web-app uses the same session-ID for each session for a fixed user. So, after logging-out of the application, next time the user is logged in, the same session-ID is released as a cookie. However, while the user is not logged in, the application disallows using the cookie (resending the HTTP requests with the same cookie are forwarded to login page).

Is this considered a bad security practice? How about if the same session-ID is used for all users?

2 Answers 2

9

Rolling your own session management system is extremely hazardous, because a lot can go wrong with a session. In PHP you should just use session_start() and the $_SESSION superglobal.

By using the same Session Id each time the user logs in, then there is no point in changing your password. There is one token that always permits access. An attacker could comprise this session with XSS, or due to Insufficient Transport-Layer Security, and then they will always have access to the system.

Using the same session for every user defeats the purpose, if you need a global state, use a database

7

Agree with Rook, however he/she doesn't point out why your proposal is intrinsically flawed when you invalidate the authenticated state of the session.

There is at least one specific vulnerability this creates: the session id is now predictable. Consider: Alice uses the system from client A - after logging out, you may have flagged the session as no longer validated, but the session token may still be recoverable from this client. Chuck comes along and extracts the session id from client A. He can't access the system because the session is flagged as not authenticated. But then Alice logs back in from client B - the session is no longer locked and Chuck has free access.

How about if the same session-ID is used for all users?

WTF???!!!!

Then it's not a session id.

You must log in to answer this question.

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