Are Sessions Redundant?

[mentalist]

If i'm going to use a cookie anyway to allow some users to stay logged in, then since sessions throw a cookie anyway, why use both?

 

 

 

*** unless I want to track visitors not logged in...

Edited October 24, 2013 by mentalist

[requinix]

Without the session cookie (that is, without sessions at all) you'd have to reauthenticate the user every single time they visit a page. That's generally unnecessary overhead.

 

Without sessions you can't securely store any information without having to retrieve it from the database every time. But how would you know which information to get? What if the user is logged in on two machines - that should be two separate contexts with two (at least partially) separate sets of information. So now you need a unique identifier to tell what to retrieve. And now you've reimplemented sessions.

[mentalist]

 

Without the session cookie (that is, without sessions at all) you'd have to reauthenticate the user every single time they visit a page. That's generally unnecessary overhead.

 

Without sessions you can't securely store any information without having to retrieve it from the database every time. But how would you know which information to get?

The real cookie stores a custom session_id.

 

I do make a db call to retrieve user info each time (joined with other data), but I see your point on not having too. However on many tutorials, including the logging in one here (I think!!) they check the user from $_SESSION data anyway (but that too is probably redundant?).

 

What if the user is logged in on two machines - that should be two separate contexts with two (at least partially) separate sets of information. So now you need a unique identifier to tell what to retrieve. And now you've reimplemented sessions.

Personally I don't like that method (Facebook uses it!), because if someone does hijack your session or even simply steals / cracks your password then it boots the other off and highlights a potential issue! Edited October 24, 2013 by mentalist

[mentalist]

On a side note would you get a performance boost by not storing data either in ram or files stored by the server, esp on lighttpd and nginx?

[requinix]

The real cookie stores a custom session_id.

So you're using sessions that you've come up with yourself instead of PHP's sessions?

 

I do make a db call to retrieve user info each time (joined with other data), but I see your point on not having too. However on many tutorials, including the logging in one here (I think!!) they check the user from $_SESSION data anyway (but that too is probably redundant?).

Doing so makes it not redundant. Having to check every time does.

 

Personally I don't like that method (Facebook uses it!), because if someone does hijack your session or even simply steals / cracks your password then it boots the other off and highlights a potential issue!

If the password is broken then the user account is lost. There's nothing you can do about that besides try to help the original user deal with the fallout (like issue refunds for fraudulent purchases). Well, you can use two-factor authentication, like an answer to a security question alongside the password, which would make it harder to "hack" into someone's account, but my point is if that important information is compromised then it's all over.

Session hijacking is a problem with cookies, not just with sessions. Your system of reauthenticating is even more vulnerable because there's no way for you to know if a request was hijacked - you don't store any information associated with the "session", like user agent or IP address, to use to verify the request. So regardless of the exact mechanism, be it no session or a custom session mechanism or PHP's sessions, if you use cookies then you have to take precautions against hijacking.

 

On a side note would you get a performance boost by not storing data either in ram or files stored by the server, esp on lighttpd and nginx?

As long as you're not storing lots and lots of data in the session, no there'd be no meaningful difference. Edited October 24, 2013 by requinix

[mentalist]

 

...then it's all over.

It's never all over!

 

So you're using sessions that you've come up with yourself instead of PHP's sessions?

 

Yes. I use like name, time, a user specific nonce / iv, and some others before hashing it. That should be pseudorandom enough for a session id being used over known unsecured channels (unless wrapped by ssl, but).

 

Doing so makes it not redundant. Having to check every time does.

 

But I retrieve user data anyway to check various data (browser, ip, status (newly banned), a few others depending)

 

If the password is broken then the user account is lost. There's nothing you can do about that besides try to help the original user deal with the fallout (like issue refunds for fraudulent purchases). Well, you can use two-factor authentication, like an answer to a security question alongside the password, which would make it harder to "hack" into someone's account, but my point is if that important information is compromised then it's all over.

That's only really useful at registration and / or login.

 

Session hijacking is a problem with cookies, not just with sessions.

Absolutely, but i'm wondering why run both (when using a "stay logged in" system).

 

Also by storing the data in the server are you not replicating already stored data? (*dunno how php / server instantiates variables for sessions?)

 

Your system of reauthenticating is even more vulnerable because there's no way for you to know if a request was hijacked - you don't store any information associated with the "session", like user agent or IP address, to use to verify the request. So regardless of the exact mechanism, be it no session or a custom session mechanism or PHP's sessions, if you use cookies then you have to take precautions against hijacking.

 

See above, I do store and check such info.

 

But as to authentication, a server authenticates / identifies the session by using the session cookie, so my authentication is just as secure as its.

 

As long as you're not storing lots and lots of data in the session, no there'd be no meaningful difference.

 

 

By the way, thankyou but don't take that as me saying it's over...

[vinny42]

 

It's never all over!

 

It is, when the fat lady sings! :-)

 

 

Absolutely, but i'm wondering why run both (when using a "stay logged in" system).

 

It's up to you :-)

If your stay-loggedin system stores all the data you need, then you dont need sessions.

 

But generally, a stay-loggedin system only authenticates the user and stores no other data, because it is much more convenient to use PHP's sessions for that.

 

 

Also by storing the data in the server are you not replicating already stored data?

 

Yes, but that by itself is not a problem. The only issue with that is that the data in the session can (and will) get outdated, so if you store accessrights in the session because "it's much faster to get them from the session" then a user can work with an old set of rights for hours; the session will not be updated untill it is destroyed and the user logs i again. (I've seen pretty weird ways to get around this, like looking up the sessionfile and modifying it... yuk). So keep important data where it belongs: in the database. Use the session for volatile data.

[mentalist]

...

Yes, but that by itself is not a problem. The only issue with that is that the data in the session can (and will) get outdated, so if you store accessrights in the session because "it's much faster to get them from the session" then a user can work with an old set of rights for hours; the session will not be updated untill it is destroyed and the user logs i again. (I've seen pretty weird ways to get around this, like looking up the sessionfile and modifying it... yuk). So keep important data where it belongs: in the database. Use the session for volatile data.

TBH the group access rights is swaying me towards sessions, because there are a few lists of group items from large sets. Otherwise it's the question of the starting of the session just to have one or two variables in a slightly quicker no need to init (but is it faster because are you saying that sessions are stored in file?. Where is it stored after that, does each session have it's own memory space stored somewhere else in memory, or is it used to initalise the php virtual machine variable table (probably uses pointers rather than copying it out new each time), but the virtual machine must be running before session_start() is called surely? And then its also got to search the list of sessions too...)

 

 

Just another quick though

 

Say 1000 concurrent requests, yet say within last hour 10,000 sessions, and say username and few other vars stored, say 128 bytes...

So, 128 x 10,000 / 1024 = 1250 MB (is that right?) 1.2 GB

 

I had to recently set up a host which only had 500MB RAM and was steered away from Apache / HTTPD because of how much constant RAM it required, stating that it can easily eat 500MB and start paging out... hence why I was looking into lighttpd and nginx, but they do have issues with PHP (they prefer static pages) and multiple ssl was out for both I believe.

[mentalist]

Another thought, the use of databases has changed, the original method was to do your own checks and then just do a single call to the database, now with prepared statements that (local) network workload is at least doubled...

[vinny42]

 

Otherwise it's the question of the starting of the session just to have one or two variables in a slightly quicker no need to init

 

Indeed, sessions have limited practical use and should be used with care, just like any secondary storage method.

 

 

(but is it faster because are you saying that sessions are stored in file?. Where is it stored after that,

 

Sessions are stored as a file on disc when when you call session_start() the file is read, unserialized, and the content is place in the superglobal $_SESSION. So there is no separate storage, it's just part of your script and when the script ends the contents of $_SESSION is written back into the file. (or any other medium if you implement a custom sessionhandler (RTM))

 

 

So, 128 x 10,000 / 1024 = 1250 MB (is that right?) 1.2 GB

 

Not right; 128bytes x 10.000=1.280.000 bytes, or 1.2 MB

 

 

 

I had to recently set up a host which only had 500MB RAM and was steered away from Apache / HTTPD because of how much constant RAM it required, stating that it can easily eat 500MB and start paging out...

 

As I recall it can take 2-4MB per process, so you should be able to handle 50 processes realtively easily.

But a 500MB server is absolutly miniscule for today's standards.

 

 

hence why I was looking into lighttpd and nginx, but they do have issues with PHP (they prefer static pages) and multiple ssl was out for both I believe. 

 

nginx has no issues with php, it's not as easy to setup as for apache but it works just fine.

SSL is available got nginx too: http://nginx.org/en/docs/http/ngx_http_ssl_module.html

 

These last few questions fall into the "google first, post questions later" category. :-)

[mentalist]

Not right; 128bytes x 10.000=1.280.000 bytes, or 1.2 MB

I had nightmares getting to sleep last night realising that

 

But a 500MB server is absolutly miniscule for today's standards.

The guy almost got a 256 RAM (they were realy cheap!)

 

nginx has no issues with php, it's not as easy to setup as for apache but it works just fine. SSL is available got nginx too: http://nginx.org/en/docs/http/ngx_http_ssl_module.html

 

These last few questions fall into the "google first, post questions later" category. :-)

My problem there was delegation, who says degree graduates could be teachers out the box (UK News)... Thankyou on that (loads of examples on Google!!!)

 

 

Soooo... I got a basic framework developed last night just using cookies, the issue came when someone who hadn't checked the stay logged in, I was updating the cookie (expiration) on each request, this was fine if they clicked "do same with all cookies from this site", but if they didn't it keeps on popping up (in Opera default)... is there a better way to update a cookie than with setcookie(), a way which won't prompt another acceptance dialog?