I just want to know which is better to handle user authentication issues...

I currently use the default session handling (which is cleaner and is more portable). But should cookies be used explicitly to handle this?

Which is better? The session handling functions or the cookie functions?

AFAIK, PHP *relies* on being able to write cookies in order to *implement* "sessions", doesn't it? Once you create a session, aren't you implicitly using cookies anyway , whether or not you explicitly read or write cookies in your own PHP code?

I know that. But there are cookie functions which allow me to set cookies explicitly.

Sessions work even if cookies are disabled, but uses the query string in the browser to keep track of the session vars. I read somewhere that this may be a security risk, but I cannot seem to find it.

Anyway, most users have cookies enabled. Which way would create portable and secure code?

The security problem with encoding stuff in the URL is two-fold:

1. It's easily read (even more easily than the stuff in forms you'd have
to "view source" to see), revealing (possibly unwanted) details about
your web application's internals

2. It lends itself to cross-site scripting attacks (people can cut/paste
from the URL to manually access different parts of the web app, perhaps
subverting it).

Here's a link that gives a *much* better explanation than I'm doing (sorry! it's late ;-):
http://www.cgisecurity.com/articles/xss-faq.shtml

A great book covering an *extremely* wide range security issues is:

Security Warrior, Peikari & Chuvakin

'Hope that helps .. PSM

yes sessions will work without using cookies. the way i have sessions setup on my server i use mm to manage the sessions. this way they are never written to disk, even on the server. there is no use of any cookies at all..

sure there are some security concerns, but imo they are *at worst* balanced with cookies. the technique i use to preserve the session id is to pass the id using GET.. the requested page then checks the session id with a database that contains active sessions that allows only one session per userid.. the system checks the request against the current session, referrer url, ip address, and i had implemented a timestamp but threw it out due to being a bit of an overkill for my purposes. if anything does not match the user info in the db, the session is erased and the user is forced to login again.

while it may be possible to hijack a session using this method, it is extremely unlikely.

if you would want anymore info feel free.. i worked a while on this system and built it from scratch.. so i feel like i have a pretty good understanding of any security concerns with it..

Harishankar -

Everything Xhi is saying is correct. A couple of additional points:

1. "mm" is completely a server-side thing. It has nothing directly to do
with the "cookies vs URL" issue we were discussing:

http://us3.php.net/session
http://www.sitepoint.com/article/p3p-cookies-ie6/2

2. Here's a bit more on the "session hijacking" Xhi mentions: <= Also from http://us3.php.net/session

3. PHP "global variables" is another potential security risk. Newer
versions of PHP all default to "register_globals = false" (in php.ini):
<= Also from http://us3.php.net/session

4. To the extent you're using PHP "out of the box" (it sounds like Xhi has
done considerable work on his own infrastructure), cookies are arguably
the best, easiest, most reliable way to go.

IMHO .. PSM

true.. but i felt it is good information to throw in there if OP is going to be searching on how to setup a server to support sessions without cookies.. since it is one of only three ways to implement sessions tracking.. (there are only 3 that i know of anyhow)

im not sure about most reliable, but cookies are definately the easiest way to go.. yes it was considerably more work.. if you choose the path i did, you can rest assured you will spend a few extra hours fine tuning php, as well as a database to track the sessions.. the verdict is still not in on my system as far as reliability under load goes..

good description on the session hijacking.. that is why i would recommend doing checks on ip address and referrer url along with the session id.. and of course you are correct on the global variables.. they should *never* be enabled..

my only reasons for using cookieless sessions were that i just do not like using cookies and wanted to see if i could implement a fully functional site without cookies.. i did and so i ran with it..

I am creating a script where I cannot predict how the server set up will be like since I'll release it to the public.

My script is a simple CMS system (GPL license) with a small number of features to build a website. Actually I think at present I'll stick to the session management that is built in to PHP.

When I complete my script, I would be glad if experts could take the code, see what security flaws exist and so on.

I'm doing all the basic security things like converting form data into correct data type and converting to mysql query safe strings and such. I am also writing the code to be entire using $_SESSION vars and checking if they are set and so on.

That's what Open Source is for, isn't it? Learning something new all the time.

After reading a bit about sessions, I decided to use a cookie to encode a particular string and store it in the user's browser.

Unless the cookie is set with this value, the administrator session will not authenticate even if the session Id is correct.

Will this be of any value? Or is it weak?

yes thats not a bad idea..

one thing i had done was everytime a user is registered they have a unique hash entered in a userhash db.. you could store a hash of a hash, or hash of part of a hash, etc in the cookie and test against the admin hashes in the db..

I'm also using JavaScript to MD5 encrypt the password before it's submitted. Since this is a single user application (CMS with one user only) is that a good idea? Anyway, I guess most people have JavaScript enabled. Otherwise the password will not work.