Cookie/Session Security Question!

TheSpeedOfDark

Hey all,

I'm currently working on a site that uses SSL on another server. As a result i'm unable to transfer the session over in a normal way.

Having read a bit on this subject, it seems i'll store the session's id into a database, along with the username (username is a primary key on the USERS table).

After the user logs in, this sid is stored, and then a cookie will be set (with the encrypted sid in the cookie and on the database).
Now when the user goes to the main site, it will check that they have the cookie, and then print a welcome message as well as some other custom info.

All in all, how secure of a method is this? If you set a cookie with an encrypted value to expire after a given time, I suspect it would be unlikely (albeit possible) someone could generate a random value and try to log in with it (maybe have a script run all day to attempt this).

Does anyone have any suggestions for me in my research, or has anyone had success with other/similar results?

Keep in mind I will make cookies mandatory or else you cannot log in.
(that's ok, right?)

Regards,

Mike

jansky

in cookie you can make an expiration time
example
setcookie('name','SUperman',time()+36000) // now the cookie['name'] will expire around 1 hour

// even you close the browser and open it again you still have the cookie value

rachel2004

Mike, I'm not clear why you cannot use PHP sessions over SSL. This is pretty much standard in login forms or when users do e-commerce transactions. Is there some particular setup issue with your site(s) why this is not working?

Just to clarify, the PHP session will be stored either in a cookie on the client-side or in the URL of the user's browser. So, it's not necessary for you to create your own session ID cookie if you are using PHP session handling. And as far as expiring the session cookie, those can be specified on a global basis in the php.ini file at this variable: session.gc_maxlifetime. See this page for all of your options: http://www.php.net/manual/en/ref.session.php

If you opt to store the server-side session ID in a database, it'll be more secure than leaving it in the default /tmp directory, especially if you are in a shared-hosting environment. Bear in mind that you'll have to write some custom-session handler functions, but a Google search should pull up some simple-to-follow tutorials.

mrhappiness

TheSpeedOfDark wrote:
Hey all,

I'm currently working on a site that uses SSL on another server. As a result i'm unable to transfer the session over in a normal way.

if you start the session at http://www.yourdomain.com it will be added to all relative links and to all forms pointing to an url at this page

https://www.yourdomain.com is another page and therefor the session-id won't be added automatically.

but why don't you just try something like this:

<form method="post" action="https://www.yourdomain.com/login.php">
<?php
echo '<input type="hidden" name="'.session_name().'" value="'.session_id().'" />';
?>
<input type="text" name="username" />
<input type="password" name="userpass" />
<input type="submit" />
</form>

TheSpeedOfDark

Thanks for the support everyone. Still need more opinions if possible :-)

mrHappiness if i read what you wrote correctly, you suggest passing the sessionid from the SSL server to the non-secure website using hidden form fields?

(You had action="https" but in the logic flow for my site would be:

user goes to index.php (non-secure)
user clicks 'login'
user is redirected to SSL login.php
user logs in
user redirected to index.php (non-secure), but index.php does what we're discussing, and starts a new session (based on the old one) (somehow..)

Is it possible someone could view the source of the page, determine the names of my hidden form fields, then write their own page containing my hidden form field names, fill them with their own session id, and then post it to my index.php on the non-secure site (Have a computer program generate thousands of sid's and continue to hit the index.php until it hijacks a session)?

Would the idea be that since i'm storing this sid in the database, with a timestamp, there is a very low chance that in that window of time (perhaps an hour we'll say) that a cracker could even come close to hijacking a sessionid?

Thanks for your help thus far!
Regards,
Mike

rachel2004

TheSpeedOfDark wrote:
user is redirected to SSL login.php
user logs in
user redirected to index.php (non-secure), but index.php does what we're discussing, and starts a new session (based on the old one) (somehow..)

After a user has successfully authenticated, regenerate the session ID to make it even harder for a would-be session-hijacker. The key here is that anytime you have an escalation in privileges (as is the case when a user has gone from not-logged-in to logged-in) is to regnerate the session id. See here: http://www.php.net/session_regenerate_id

TheSpeedOfDark

That is an excellent idea! Since i'll only need to use the previous session id once to obtain the userid from the database table, i can then start a new id.. Great

ok let me just explain formally now the aforementioned, so you can share your thoughts:

User logs in from secure login.php
userid/sessionid stored in a userid,sessionid pair in the database where sessionid is a primarykey
sessionid is posted over to index.php (non secure) in hidden form fields
Database is queried for what i need from USERS table where sessionid matches on the SESSIONID table
Start a new session, and kill the old session id from the SESSIONID table.

I guess I wouldn't need that session id anymore anyway, right? We've already selected all we need and added it to a new session on index.php
If that's the case, the cracker doesn't have time to do any malicious work?
Even if someone was able to steal the session id from the hidden form fields as it posted over to index.php, the index.php script removes that session id immediately from the database table and starts a new session.

Are there any other areas I should consider regarding this process?

Regards,
Mike

rachel2004

http://www.phpbuilder.com/columns/ying20000602.php3

http://www.zend.com/zend/spotlight/code-gallery-wade8.php?article=code-gallery-wade8&kind=sl&id=7209&open=1&anc=0&view=1

check these out to keep you from re-inventing the wheel, friend. They're oft referenced (especially the first one) and will probably give you some ideas on how to begin. Hope this helped.

TheSpeedOfDark

Alright i'll check it out. I think i even read the first one, but never had the need until now to do it.

Thanks,
Mike

TheSpeedOfDark

Rachel (or anyone)

what do you think about merely doing this:

As user signs into secure page, add name and sid to database table
redirect user to unsecure login page, pass sid (i guess with post).
On non-secure page select the values i want from the database matching the sid, delete the sid from the table, and assign a new session with those values i retrieved.

This session doesn't contain too much, just a user name, and a few things about their past purchases.

This is more a re-iteration of what I said before, but having read through a lot, i've realized I don't need too much overhead of what was mentioned, b/c I can start the new session on the unsecure page, and php will handle everything else
normally. This is running on yahoo by the way. What do you think?

Regards,
Mike