0

What is considered to be common practice for limiting the session expiration for non-authenticated users? The reason we are using a session for guests is to prevent cross site forgery requests when guests submit a form. We are considering implementing a session keep alive for guests as well as admins, or extending the session expiration to something longer than php's default 24 minutes in the case of non-authenticated guests.

Clarification: This question is in regards to anonymous guests, which do not log into the site.

TheJulyPlot
  • 7,829
  • 6
  • 32
  • 44
Tadd Eells
  • 1

2 Answers2

0

I would recommend using several unique identifiers in this case, e.g. user's cookie with some random and unique string, let’s say USER_ID, and a session token e.g. SESSID. The session token should expire as it is supposed to, however the USER_ID remains. This way you will be able to identify users, who have previously visited your website and still use new SESSID as protection against CSRF.

Extending lifetime for sessions is not a good idea, especially if you use this token to verify user's identity (in case with admin account).

Valery Marchuk
  • 546
  • 2
  • 6
0

It depends on how sensitive the actions users can take are, and on how confident you are that session tokens are safe. For example, most banks will automatically destroy sessions after say 15 minutes of inactivity, on the other hand Google account sessions can last indefinitely.

If you set the HttpOnly and Secure flags on your session cookie you can be reasonably sure that it can't be easily stolen, and personally I would be quite comfortable with it lasting over a month. If you can't use HttpOnly and Secure (especially Secure) I would probably limit it to less than a day, or even an hour.

If I'm understanding Valery Marchuk's answer correctly, it would provide no benefit and would make session hijacking trivial if USER_IDs are predictable (I would comment but I don't have 50 rep).

AndrolGenhald
  • 15,696
  • 5
  • 45
  • 51