1 Topic by RNilsson (edited by RNilsson 2003-09-05 02:47)

  • From: Göteborg
  • Registered: 2003-02-25
  • Posts: 168

Topic: Sessions & Cookies

I'm constructin a user-login-system that will contain both sessions (for carrying info between pages) and cookies (to allow a user to remeber login).

Now, since i'm gonna use both, i want to authenticate the user if a cookie is present, and redirect to a loginpage if cookie is not valid.

I want to use sessions to "remember" the authenticated user, so i don't have to verify the user on each page-view, but rather compare a session-value with some value in the cookie, and as long as they are in agreement, another authentication against db does not occur.

The sessions will also remember login-status for the duration of the visit if the visitor doesn't want to store a cookie on the computer (The stupid swedish law)

I pretty much will have these functions to do the work for me:
requireMemberStatus - For pages that require member-status or above.
requireAdminStatus - For pages that require admin-status and not available for regular members.

setSessionHandler - First time the session is set with info
updateSessionHandler - The session gets updated with info
destroySessionHandler - When the user logs out (ie, from a public pc for instance)

setCookieHandler - Create the cookie if the user wants to
updateCookieHandler - Update expiretime and session-info on each "verify"
destroyCookieHandler - nuke the cookie

doLogin - Verify the user against the db
doVerify - Validates the cookie and updates the session and cookie
doLogout - Clear up everything...

checkStatus - Checks to see if the user is authenticated, member or admin (return 0, 1, 2)

Now to my problem...
I'm not entierly sure how to make this work as i haven't worked with cookies before and don't quite know how to make a secure varify/auth of the cookie...

Also, what happens with the cookie-authentication/validity if the user is changing computer regulary, like home-machine/work-machine and gets new sessionid's etc between visits?

Ideas, comments etc is welcome...

2 Reply by Mako (edited by Mako 2003-09-06 19:26)

  • Mako
  • Senior Member
  • Offline
  • Registered: 2003-08-24
  • Posts: 200

Re: Sessions & Cookies

You can carry information between pages using cookies you know.

Go here: http://us3.php.net/manual/en/function.setcookie.php

---------------
Take notice this on that page
---------------
Parameter: secure
Description: Indicates that the cookie should only be transmitted over a secure HTTPS connection. When set to 1, the cookie will only be set if a secure connection exists. The default is 0. 
Examples: 0 or 1

"You start coding. I'll go find out what they want." - Computer Analyst to Programmer
  • From: 127.0.0.1
  • Registered: 2001-11-02
  • Posts: 9,167

Re: Sessions & Cookies

Sounds like a good layout. There is one problem though. If you don't validate the users session every page view, it will be easy to hijack someone elses session by just getting hold of their session ID. It's quite common to attach an IP address to the session ID and then for each page view you make sure that the visitors IP address matches the session ID.

"Programming is like sex: one mistake and you have to support it for the rest of your life."

Rickard's Website

4 Reply by Mako

  • Mako
  • Senior Member
  • Offline
  • Registered: 2003-08-24
  • Posts: 200

Re: Sessions & Cookies

Or instead of verifying it with their IP address, you could just MD5 a variable and use that to verify stuff.

"You start coding. I'll go find out what they want." - Computer Analyst to Programmer
  • From: 127.0.0.1
  • Registered: 2001-11-02
  • Posts: 9,167

Re: Sessions & Cookies

Hmm, how would the MD5 hash be distributed throughout the pages?

"Programming is like sex: one mistake and you have to support it for the rest of your life."

Rickard's Website

6 Reply by RNilsson (edited by RNilsson 2003-09-06 23:33)

  • From: Göteborg
  • Registered: 2003-02-25
  • Posts: 168

Re: Sessions & Cookies

Do you verify the user on each pageview in pun?
That is, do you query the db with userinfo?

I had an idea of putting some known variables, like email, remote_addr, username and some md5-hash in the cookie, and the same info in the session-vars and maybe use a loginTimeout of 60 or 120secs, and thus check if the timeout is older the X secs and do valitade, or if the cookie-info doesn't match those in the current session-vars do validate the user.

I'm looking to put the least stress on the db as possible, while maintaining a reasonably high security for the members, ie making sure that the persion is who it states.

EDIT: And i usually make md5's of info that does not -need- to be cleartext, like username for instance.

Thus a bunch of md5-hashes of the above variables in the cookie should be pretty safe?

  • From: 127.0.0.1
  • Registered: 2001-11-02
  • Posts: 9,167

Re: Sessions & Cookies

Yes, I verify the user on each pageview. All scripts require access to one or more variables from the user profile, so I have to do the query anyway. Also, it's just a simple SELECT on a table with index for the user ID, so the query is very fast.

In PunBB I do the following (from 1.1):

- Fetch the serialized array from the cookie.
- SELECT * FROM users WHERE username=username_from_cookie AND password=hash_from_cookie
- If I get a row back, I know the user is logged in. Otherwise the username and/or password in the cookie is incorrect.

"Programming is like sex: one mistake and you have to support it for the rest of your life."

Rickard's Website

  • From: Göteborg
  • Registered: 2003-02-25
  • Posts: 168

Re: Sessions & Cookies

Ok.

I've got a hypothetical here:
I put the username, md5-hash password, ip, lastVerify in the cookie.

I put the sessionid, username, ip, lastVerify in a session.

On each page i check if the cookie-info corresponds to the session-info and if they match, then the user should be who they say they are, and if the session and cookie-info doesn't match up i force them to login (the cookie/session might be hijacked).
If the session & cookie match up, but the cookie is older then, say, 120sec's, verify the user against db to make sure all is ok (take sessionid & ip from the session, username, md5-password & ip from the cookie and all 4 must be present in the db to validate the user.

Stored in the db on the user-row is: username, sessionid, md5-pass, loginIP.

Of course i would make an option to bypass the ip-check if user is on dialup for instance with a field-value of 1/0 or similar.

I would like to not have a db-check on each page, but rather in a timed manner, mainly if the db is hosted off-site.

Wouldn't this be a viable option, or am i way off here?

  • From: 127.0.0.1
  • Registered: 2001-11-02
  • Posts: 9,167

Re: Sessions & Cookies

I think it sounds good. I can't think of anything not good about it :)

"Programming is like sex: one mistake and you have to support it for the rest of your life."

Rickard's Website

  • From: Göteborg
  • Registered: 2003-02-25
  • Posts: 168

Re: Sessions & Cookies

Heh, sound good then, i'll give it a go...

11 Reply by MarcB

  • MarcB
  • Senior Member
  • Offline
  • Registered: 2004-02-13
  • Posts: 124

Re: Sessions & Cookies

I wouldn't revive this topic if I didn' find it really interesting from the security point of view.

My objection would be that it's just as easy to hijack a cookie as a session ID, so if you somehow circumvent the ip check, might as well just use a cookie, even if you're checking against the DB.

So my advice would be to create new sessions, use cookies that expire as the navigation window closes or the user logs out (if they do it from some internet cafes, they're not allowed to close the navigator).

Even so, I'm worried about IP spoofing, but I can't do much about it, I'm currently working on such a system. Cookies are two times encrypted: IP+seed for the first layer, then a user-dependent seed for the second layer, where I obtain the password hash. That I verify against the DB every time. I don't see the advantage in overloading the web server, since I found out that usually the DB server is idle most of the time.

I might sound a bit paranoid, but these are simply requirements for this type of apps (I usually do banks... in the good sense, that is, I don't rob 'em wink ). The only advantage I see in using the session is that you know that the user logged in previously, but you can as well add his IP to a database field when he logs in, the process doesn't even need to be synchronic, and add an additional field to the where on verification.

The other point, is that you overestimate user speed. If you're designing an application (for a forum or the likes, there are better security settings to tweak), users musg be doing something, and that usually takes lots of time.

In my case, every page is meant to supply/update info from/to the database, so since I already must open a connection, what the hell, I might as well verify the user.

I just don't know, many of these might be prejudices, and since this thread is quite old, you might have already implemented this system, what's your feedback? I'm always very interested in discussing security improvements.

Marc