Sessions And Cookies

[masterlayouts]

I am a little confused about session/cookies automatic interaction/behavior. You explained that it is preferable to store the email (users.email) in session and not the userID (users.userID) because the email is harder to forge than userID which is a number, hence leaving the site exposed to XSS attacks.

 

However, for whatever operations the user may be allowed to do, like CRUD operations, you will need the id of the table for that specific action (let's say "posts" table, for example, we will need something like posts.postID) and the userID. To get users.userID from users.email we will have to make a SELECT query every time, as opposed of having the userID stored in the session, hence a query less every time.

 

It seems to me that will be a lot more convenient to store the userID in the session. You said that it will not be a problem to have the userID stored in session as far as we do not have it stored in cookie. Here I am a little confused, because I do not understand how setting the userID in session become a cookie problem (as the argument against using the userID in session is predicted on leaking the value in the cookie and I do not understand why).

 

I do not stored anything explicit in a cookie, will a cookie be always created when starting a session? What it will contain if no explicit value/parameters were given?

 

If I stored the userID in the session, should I be preoccupied that it may leak in the cookie without knowing it? Is it a common behavior for the cookies to replicate sessions?

 

Should I explicitly set a cookie every time to overwrite odd behavior or is it possible to let the cookie work automatically and do the job only from session?

 

Shouldn't cookies and sessions be isolated and work separately?

 

I am guessing all problems start with directives like the one you suggested on page 357. What is the effect of "ini_set ('session_use_only_cookies', 1)" when you store the userID in the session and no cookie was set explicitly?

 

Why don't we simply use a salt and hash the value? Isn't more beneficial this approach considering that it should be safer and we end up having the userID stored, which is much more practical to use than users.email?

 

You presented cookies as being safer from one point of view. However, sessions are stored on server, shouldn't be safer to use sessions? I see a reason why using cookies to store user settings (as selected language for the forum, for example), but I do not see any good reason to use cookies to store sensitive information as the userID. If the argument, as I understand it, is that whatever a cookie holds it can be forged easily because it is easy to guess numbers, I do not see why it is not a big problem this behavior in the first place or why does it feel safer as chances are the attacker can very easily know the email of the victim, hence being in the same situation as when using numbers. It looks more secure, but in my opinion it is a false sense of security. Emails can be as easily be guessed (or known in advance) as numbers, it is not such an important defensive mechanism. I guess my point is: never use cookies when safety is paramount... maybe I am wrong.

[Antonio Conte]

The problem comes down to users changing cookies. Let's say you base your login system on cookie verification of user id. If a user changes his personal cookie to the ID/email/whatever of an admin, he soon has all the privileges too. Sessions are also hashed. Retrieving other users data is also therefor harder with sessions than cookies.

 

Do you know how standard PHP functions like trim(), strlen(), etc really works behind the scene? Do you care? All you really care about is how to use them. The same applies to cookies/sessions. Just read the recommendations and move along. Someone much smarter decided this was the best solution. Stick to that unless you're a rocket scientist.

 

For the email/id part: Store both. Use the id in CRUD operations, but don't test logic like if the user is logged in, an admin, etc with it. That is a better suited job for emails, as they are harder to replicate the hash of.