User Authentication Method?

alsaffar

Hi there,

Which one is better to use for user's authentication, cookies or sessions?

I just started coding a nice script for handling User's signUp and login using cookies, and I found that if the user forgot to logout and the cookie is not expired yet, any one can log to any page using the first guy userName and password in the same PC, cause I put at every page a small code to grab the userName and password from the cookie I set.

So, any idea how I can delete the cookie automaticaly when the user close the session and forgot to logout?

midol

My PHP knowledge is no where near perfect, but from my experience this works well.
From my understanding, you can just use sessions and never place a cookie. That will allow you to access all the variables from the time they login to the time they close browser. Then next time the user returns they will need to re-login. You might want to include an option for it to auto log them in. For that you would simply place a cookie on their computer w/ their session ID. Thats just incase you want people to have the ability to logout each time or be able to return w/o re-logging.

benwestgarth

Also, be careful when implementing sessions and test them well with all browsers. Internet Explorer has displayed some strange behaviour (at least strange in my opinion) when I have developed pages using sessions. At the very least it handles them differently to Mozilla and other browsers.

mykg4orce

if you are sending a pure username or password to a cookie, its probably a good idea to encrypt them, atlest the password. 🙂

MrAlaska

Originally posted by alsaffar
[Which one is better to use for user's authentication, cookies or sessions?

I have been seriously investigating such questions and still find myself on the beginning of the learning curve and open to suggestion, but from what I have found out so far that is not really a fair question in itself, which one is 'better'. Sessions and cookies are not a one verses the other. Sessions do two jobs, maintaining state and offering a convenient and relatively secure place to store variables.

Sessions are not just authentication, they are a kind of a built in package to take the load off you as a programmer. Sessions use cookies by default to maintain state but URL encoding the session ID is also available, and kicks in automatically if the user has cookies turned off. If you wish to store a variable in a session it is kept track of by the server and unavailable to packet sniffers.

The price you pay may be a performance hit, possibly a significant one. Sessions have a built in additional overhead per visitor on top of everything else which is the RAM used for storing the various pointers and whatnot per session, the extent of which I have not yet been able to find documented for PHP. With JSP the amount quoted to me was 256k per user, with IIS it was 'probably quite a bit', I have not found anything to indicate how much PHP uses.

Another consideration when sessions are turned on may be whether you really need to maintain state on ALL your visitors. If you have a shopping site with 2000 visitors but only 20 of have evoked the shopping cart, do you really need to maintain state with the other 1,980 visitors? Even if the sessions are not authenticated, the server still might partition RAM to keep track that this user/session is NOT authenticated. This is one question that I have been unable to find the answer to, but with other server languages you are indeed suffering the additional overhead.

On the other side of the coin, everything a session does is available to you also, but you then need to handle everything with your scripts. To maintain state, you can generate a unique ID and place it in a cookie or encode it in the URL just as a session does. Storing the variables then becomes your responsibility also. You can either store them in files as sessions do, put them in a database, or put them in the cookie (which may have some serious performance and security considerations).

So far from what I have been able to dig up there is not really one answer. Depending on your site you may be able to handle state and store variables much more efficiently on your own, or you just might find that sessions pay for themselves.

MrAlaska

Originally posted by alsaffar
I just started coding a nice script for handling User's signUp and login using cookies, and I found that if the user forgot to logout and the cookie is not expired yet, any one can log to any page using the first guy userName and password in the same PC, cause I put at every page a small code to grab the userName and password from the cookie I set.

So, any idea how I can delete the cookie automaticaly when the user close the session and forgot to logout?

That is another question altogether. If the user is still logged in other people will still be able to cruise through the account if they have access to the browser the user was using. If you set a cookie without setting an expiration date, it is the same type of cookie that sessions use and it will be destroyed when they close all instances of their active browser.

Sessions also expire after a pre-determined amount of time of inactivity. If you are handling sessions with your script, you can do the same thing by invalidating the active log in if it has been more than an amount of time you determine since they were active.

the_Igel

Anyway, one should NOT put the password in the cookie, especially in plain text. I usually use a cookie for session id and store everything in MySQL, 'cause most servers i work with run php as cgi.
And sure one should set expire time for the cookies.

alsaffar

Well, I tried not to set the cookie to an expire time, I just left it blank "", then I login as any user, and the browser asked me for setting myDomain cookies, after accepting those cookies, I logged in, and I can check that the cookie was set and I can get any information I need from this cookie like userID and UserName and Password via a script I made,

then, before I closed my session, I checked my cookies folder in my PC and I couldn't find my cookie there!!! so the cookie isn't stored at all in my PC even in the session life,

CONCLUSION:

SO, if I didn't set the expiry date, and the session is not closed yet, the cookie will not be stored at all on the user PC, and so, no one can edit that cookie to gain through my database,

so, I think using cookies with no expiry date is secure enough.

QUESTION:

Any comments on my conclusion?

MrAlaska

Originally posted by alsaffar

CONCLUSION:

SO, if I didn't set the expiry date, and the session is not closed yet, the cookie will not be stored at all on the user PC, and so, no one can edit that cookie to gain through my database,

so, I think using cookies with no expiry date is secure enough.

QUESTION:

Any comments on my conclusion?

It is true that the cookie is not stored on the hard drive, it is the same type of cookie php sessions use. However, you must bear in mind it is still on the clients machine and still under the client's control, so you cannot trust it. He can control it at the port level and nothing you can do about it.

Also, anything in the cookie is going back and forth over the wire, so unless you are running SSL the information is available to anybody who wants to grab it.

To be secure, your best bet is to do the same thing as sessions do. Store nothing more than the unique identifier on the cookie, then validate it against your server stored records to insure the visitor is who the cookie says the visitor is.

alsaffar

Store nothing more than the unique identifier on the cookie, then validate it against your server stored records to insure the visitor is who the cookie says the visitor is.

Q1. Now I'm storing the UserName and md5(Password) and UserID (There from Users Table in mySQL) in a cookie, and in every page that I need to check anything about the user, I just take the UserID and make my query upon it.

Now you're telling me just to store a unique identifier id (Do you mean SessionID?), what's the benift beyond that? How I can check who's is this user? (ofcourse after he login with his UserName and Password).

Q2. And one more thing, everybody said that if the user set his browser not to accept cookies at all, then the nest solution for this is to use session. When my script include the session_start(); command it prompt to the user that if he want to accept the cookie or not? that means if the user set not to accept the cookie (from my domain for example) then even sessions will not solve the problem!

MrAlaska

Yes, by unique identifier I meant a session ID, except one that is generated by yourself instead of the system.

If a user does not have cookies enabled, the next move is to put the session ID in the URL (as PHP sessions do) or in hidden post inputs.

You questions are being answered more comprehensively by mrmufin in this thread:
http://www.phpbuilder.com/board/showthread.php?s=&threadid=10208260
As he steps through the details of his own 'Roll your own session'

EDIT: BTW, by storing the UserID, UserName, and Encrypted Password on clients system, a hostile user can eavesdrop on your clients packets then hijack your client's account whenever he wants.

With the sessionID method, you keep the information on your own system where it is safe, then validate it against information you gathered on your client when he established the session.

NiXXeD

Ok, there was a LOT to read in this thread, so I only glanced at a bunch of it. Sorry if any of this is repeated. What I do for user auth is I use a mix of sessions and cookies, but it relies on cookies. I don't like the way sessions change the URL and add all the sessid stuff into it, so I turned that feature OFF. I store the sessid in a cookie, and just load the sessid from the cookie when I'm starting up the session. This way, people can 'stay logged in' and all their data is stored in the session on the server.

mrmufin

Originally posted by NiXXeD
What I do for user auth is I use a mix of sessions and cookies, but it relies on cookies.

And when a user hits the site who doesn't have cookies enabled, what happens?

alsaffar

Thats my question, if the user choosed to block all cookies. How can we live after 😕

NiXXeD

Originally posted by alsaffar
Thats my question, if the user choosed to block all cookies. How can we live after 😕

Well, what you do then is leave on the URL sessid setting and make sure that in each page you register that session id before you start the session. That way the people without cookies are missing features, but for the normal users, it works too.

MrAlaska

Originally posted by NiXXeD

Well, what you do then is leave on the URL sessid setting and make sure that in each page you register that session id before you start the session. That way the people without cookies are missing features, but for the normal users, it works too.

If I am reading you right, it appears you are making more work on yourself, the server, and the network than you need to.

If you have sessions turned on with session_start(), you can set PHP to handle all that in the PHP ini settings. PHP can detect whether cookies are turned on, then use the session in the URL method only if cookies are disabled.

If you are using cookies to maintain state, you can take over putting the sessionID (one YOU generated) in the URL if cookies are off, then do not start sessions at all. Of course, all the variables you are storing in the session will then need to be stored by yourself, either in a file (as sessions do) or in your database.

I think you would do well to pick one or the other, not both. I am a fan of doing it all yourself, but letting the PHP server do it is much simpler.

Namadoor

I find sessions can do wired things. So be carful if you choose to use them. Not all people can use cookies, but I took a poll and found that about 95% of them can have cookies. It also depends on weather or not they choose to accept them. I went with cookies for my site, and I find them easier to use then sessions.

alsaffar

Well, they (Programmers) said that it's easy that the user can hack your db by manipulating your cookie on his PC. Because of this I got afraid to use cookies cause I don't want any hole to my DB.

I find sessions can do wired things. So be carful if you choose to use them.

So, what did you find it wired about sessions so I can avoid it?

MrAlaska

Originally posted by alsaffar
Well, they (Programmers) said that it's easy that the user can hack your db by manipulating your cookie on his PC. Because of this I got afraid to use cookies cause I don't want any hole to my DB.

Sessions offer two methods of maintaining state as can be determined in your configuration, or a combination of the two:
1) cookies
2) URL encryption

URL encryption is MUCH easier for a user to hack into. Even using sessions, you still need to run your own verification to insure the user is who he says he is. I don't think sessions actually validate against anything other than the ID number from what I have been reading in the documentation, somebody please correct me if I am mistaken.

alsaffar

Come on MrAlaska you'll make me hate myself 🙂

URL encryption is MUCH easier for a user to hack into. Even using sessions, you still need to run your own verification to insure the user is who he says he is.

So, if the user disabled the cookies on his browser and then the URL ecryption will be the last solution for the script to take place. After that you're saying that URL encryption is easy to be hacked, this will lead us to say that even using sessions, our DB will be easy to be hacked. Come on, so anyone who wants to hack a DB, if the website is using a cookie then it'll be easy for him to manipulate that cookie! or if the website is using sessions, then he'll disable cookies to see the URL encryption in the address bar, and then you're saying it'll be easy to be hacked!!!!!!!!!!!!!!!!

What should we do?