Authenticating Users: Cookies or Sessions

registered · Posted: Mon Jul 30, 2007 4:12 pm

In my toy CMS I am building the admin part (my CMS only has admins right now). I have studied how Nuke currently does authentication using a cookie. As you probably know, it takes your username and hashed password and puts that together in a string separated by colons. To then further obfuscate things, it base 64 encodes it. I suppose this keeps casual prying eyes from discovering details. But this is open source, so one merely has to look at the Nuke code, see what is being done, and then do a base 64 decode and suddenly you have a username and hashed password. Most articles I have read have not recommended that you authenticate users with such a cookie scheme, as many spyware programs steal cookies.

I've been reading that PHP Pro Security book and in there they talk about sessions. Now sessions also have their pitfalls, and unless you are using SSL, the session ID is going over the wire unencrypted. Someone could sniff that out and hijack the session. (The same can be said for ftp). The book also discourages additional tricks you could do like looking at the user agent, referrer, etc. I think phpBB is trying to do something similar. The books says all those things are easily spoofed and aren't going to stop a determined adversary.

Also with sessions, it is imperative you implement them with cookies, and not let the transparent ID creep into the URL's. Otherwise links with the session ID could creep into server logs, etc.

So all in all, I am leaning towards sessions vs the existing Nuke cookie scheme. Any thoughts on this?

To me, sessions seem much simpler, at least as secure (maybe a little more), and you could also squirrel away other things in the session to save on database calls. And if security became a real issue, you just switch your site to SSL to prevent session hijacking and no code changes need to be made.

Posted: Mon Jul 30, 2007 4:15 pm

Also, my understanding is that the cookie used to implement sessions is an in-memory cookie and defaults to being destroyed when the browser is closed. So you don't have to worry about spyware stealing that cookie (at least through the normal means for regular persistent cookies).

Posted: Mon Jul 30, 2007 5:57 pm

Gremmie, you are just too fast! I was just reading about this too but I hadn't gotten to posting anything. I use native PHP sessions in the two modules I wrote before I ever heard of Nuke (actually they were applications at that time but I translated them but stayed with sessions and my own security_groups table). They work like a charm.

There are a lot of good articles if you google PHP sessions security or something like that. One recommends using the HTTP user agent in addition to the session ID and another writing the session id out to a table. Apparently web hosts write sessions in progress to the /tmp directory which anyone else on that server could hack. Raven might have a better idea about that.

What I have experimented with is writing the config values that are read in in mainfile into session variables and then retrieving from there instead of doing SQL calls hundreds or thousands of times throughout a "session". I have actually run this successfully but I sidetracked it for RN2.10. I did find that session array variables are tremendously inefficient and you just need to use regular session variables. I'm sure that's PHP implementation dependent but it's a fact of life.

I'm pretty sure we could "encapsulate" the is_user and is_admin and various other functions in mainfile that are executed repeatedly (the current static variable test does nothing to stop the SQL from being executed) within a test for whether the session variable exists and load from the session variable if it does bypassing the SQL.

You are right about implementing with cookies and keeping them out of the URL. But otherwise I'd be inclined to go with pure native PHP sessions and not a lot of the other crap that people are doing to obfuscate (but not really secure their sessions). I'm not developing financial systems on PHPnuke anyway and never would and you are right we'd need SSL for that.

I'm not sure there has to be an absolute dichotomy between the current cookie scheme and sessions. The values could be read out of cookies and used for the duration of the session and then the session destroyed. I'm not sure that there have been actual compromises of the current cookie scheme ... but I guess if we could eliminate it that might be even more secure.

Posted: Mon Jul 30, 2007 6:17 pm

And here is the url for the Code Igniters discussion of sessions.

Only registered users can see links on this board! Get registered or login!

Interesting that they roll their own sessions. I think we could get everything we need to store for Nuke in 4kb.

However, searching on "sessions" in their forums there is quite an extensive discussion and quite a number of options.

Posted: Mon Jul 30, 2007 7:54 pm

Thanks. More interesting reading. I had not heard that about array variables inside $_SESSION. Is that just with PHP4 or 5?

I also agree about the obfuscation tricks. Just use the native PHP sessions; we aren't developing a financial system here. If you really do care, use SSL.

I suppose you would have to profile storing a lot of stuff in a session versus reading it out of the database. The database may in fact still be faster. Sessions are probably written out to a file (like in /tmp), and they may actually be not as optimized like MySQL is. And that is something that could change between PHP4, 5, and 6, etc. And you could certainly mix and match things in sessions, cookies, or the database.

I just got sessions to work with my toy CMS for determining if someone has logged in or not. It is pretty slick and easy to do. Much better than all that crazy is_user() stuff.

BTW, I took today off so I had plenty of time to read and code PHP today. I'm not normally this geeky. Smile

registered · Posted: Tue Jul 31, 2007 5:10 pm

Yes, I believe $_SESSION was available in PHP4 as well. I personally would not be too concerned about session hijacking, especially if you change the session id every so often, say after 5 minutes or so. I think it is good enough. I am with you on using cookies. Definitely not as good. Of course, I have also heard of there being issues on some hosts with the set up of sessions, but I prefer to force those hosts to "get a clue". (this was noted as an issue by Technocrat with his captcha - not issue with the captcha, but the host set ups).

You are also right that the session info is stored on the server in small files. It could be tmp or another directory depending upon the set up. I think even fkelly had done some performance tests with sessions and I thought he found some performance degradation vs. mySQL. I don't have much to offer by way of what makes sense vs. not, only to say that I have typically seen small chunks of data stored in sessions rather than trying to stuff them full of stuff.

Posted: Tue Jul 31, 2007 5:28 pm

BTW, I could be wrong on this, but I am thinking base64 encoding may have been more for the purpose of ensuring the cookie can be stored and read properly rather than being a security thing. I think it has something to do with what can be passed in the HTTP headers (which the cookies are)??????

Again, not 100% certain, but my "gut" tells me that might be why it is really used.

Posted: Tue Jul 31, 2007 5:43 pm

To be honest, I just guessed at the security reason. Glancing at the php.net page on set_cookie() it doesn't indicate anything about restrictions on the format of the value string. It says that it will automatically be urlencoded and decoded for you.

It also says this: do not store sensitive information. Wink

Posted: Wed Aug 01, 2007 7:47 am

A previous thread was here:

Only registered users can see links on this board! Get registered or login!

I am rummaging thru the myriad mainfile versions I have to see where I left it. I do recall that accessing a session variable in an array was many time more "expensive" than a simple session variable. In other words if you say $_SESSION['sitename'] it is pretty much the same as accessing a normal variable but if you do something like $_SESSION['config'] = array("sitename" => row['sitename'], "nukeurl" = row['nukeurl'], yada yada ...

and then try to access the array elements it is much more costly. The performance statistics are from PHPED. Also if you go over and access:

Only registered users can see links on this board! Get registered or login!

you can see some actual performance statistics. The lesson: avoid SESSION ARRAY VARIABLES. (and note: since this is now running on Raven's server and that's PHP5 the problem has not been fixed in PHP5).

I think that to really test this I need to pick up where I left off a year ago, stuff the config values plus what's now in cookies into session variables and recode is_user and is_admin to check to see whether a session is set and use that instead of a SQL call if it is. As you said earlier this could actually be more inefficient if it has to read from the filesystem rather than the database but I just think we don't know. I do know that if you look at the statistics in PHPED the SQL statements are the ones that eat the majority of resources in a given run (enter key to enter key). Also, if you look at the SQL statements that are executed during a run you will see tremendous duplication: almost every NUKE module or block that's run will independently access is_user and whatever SQL is in there. There just has to be a way to cut that down.

To be continued ...

Posted: Wed Aug 08, 2007 3:21 pm

This thread was moved here from an Internal area in order to get feedback and input from developers throughout the community. As indicated above, I've been looking for some way to avoid reading and rereading the configuration table on every pass thru mainfile as well as other ways to reduce or eliminate unnecessary SQL calls. And Gremmie has discussed other cookie and sessions issues. In following up on a lead by Montego related to Nuke EVO I started looking at what they are doing with caching. Very interesting but I don't fully understand it.

When I started looking at sessions as a mechanism for storing config values "during a session" I was falsely assuming that they'd be "cached" in memory. Later I found out that they are just stored in a sequential file on the server. So that raised the question: would they be any more efficient that just rereading the config table. I don't know yet. But then looking at EVO they have a much more sophisticated means of caching -- it appears there is an option to use a file or a MYSQL table. But I'm still not clear what the advantage is if you have to go do a read every time. To me "cache" means stored in memory where I/O is unnecessary, at least to disk.

So I am hoping Technocrat sees this and can enlighten us and that others who are more knowledgeable than I can help out too. Thanks.

Posted: Thu Aug 09, 2007 7:05 am

Yeah, sure which PHP had some J2EE features... Can anyone say PHPBeans? Laughing

Posted: Thu Aug 09, 2007 8:44 am

Only registered users can see links on this board! Get registered or login!

States that caching using the filesystem can be faster than reading the data in from MYSQL. I'm not sure that's what EVO is doing but it looks like it.

registered · Posted: Thu Aug 09, 2007 10:11 am

As montego pointed out some webhosts incorrectly setup their sessions. Thus sessions will launch and you won't see errors or anything. It just won't store data. It's rather annoying the first time you run in to it because you have no idea why it's not working as it should. I run into this at least once a month.

My advice is salt your passwords. Even if you use the username as added salt, it will make it much harder for someone to use a rainbow table against them. Just remember that if you do you need to keep in mind that if the username changes you need to re-salt the password. If not your in trouble.

Also you can speed things up by using static variables and is probably what you should start with before adding cache.

There are two choices for cache in Evo either file or SQL in a large blob. The file is the most optimal as it is much faster. Problem is not everyone could use file due to restrictions or safe mode.

The file or the SQL is full of variables that are included and loaded for every user. The down side is the overhead. Lots of users make the memory get big fast.

I am thinking about trying to break out the cache for v3 by making it for particular uses. For example you don't need the cache for admins if your not an admin. You don't need user cache if your not logged in. Hopefully that will prune down memory usage.

Having spent a lot of time working with caching I found a few things to be true.

First alway implement a ttl or time to live. We made it 1 week, but I think 1 day would be good.

Second always remember to have a cache cleared or updated every time you change something that affects what is cached. I forget this sometimes and it can be annoying trying to figure out why settings are not saving.

Third cache is not as fast as standard php functions. For example we were started to cache file_exsits results. Turns out that the function was twice as fast as the cache retrieval. So obviously built in functions are optimized and much faster.

Posted: Thu Aug 09, 2007 11:50 am

Wow, excellent input technocrat! Thanks.

I cannot recall if I said this before, but with sessions, regarding session hijacking, you can also reduce the risk of that by generating a new session id every so often, say, every 5, 10, or 15 minutes. From the way I understand it, the data is copied to the new session id and the old one is destroyed.