[web] Sessions In PHP [ retitled ]

Well, I'd say (and I'm probably far from alone on this) that sessions are the way to go. It's all done server-side, so it's much more secure, and you don't have to worry about the client having cookies disabled.

Everything else looks about right.

That's right. You don't even really have to store the password information in the session on the server. Just register a session variable in PHP called $userId or something when someone successfully logs in. At the top of each page, check if that variable has bene registered. If not, redirect them to the login page.




~BenDilts( void );

Ok so sessions in PHP, is that a topic in itself?

If i declare a variable in one file, is it available in another?

Dave

Yes, it is a topic in itself (which provokes several security questions), but the easy explination works like this.

At the tope of each .php file that generates a web page, type:

session_start();
global $HTTP_SESSION_VARS;
$UserName = $HTTP_SESSION_VARS['ValidUser'];


Once a user has logged in, make sure you say say:

$HTTP_SESSION_VARS['ValidUser'] = $ValidatedUserName;


The global declaration makes the value available on all pages. Session_start() starts the session.

Ok thankyou,

Dave

Lots of info at php.net too.

Also, use $_SESSION instead of $HTTP_SESSION_VARS. The latter is deprecated.

So im not storing anything on the client machine?

Right. Sessions as described above are stored entirely on the server, with no real way to get at them from the outside.

Dave: The PHP session stores data in cookies if available, otherwise it reverts to propagating it through the URL.

Beandog: Wrong. There is no way to hold a session secure over a stateless protocol like HTTP in any other way, if it only were server side it would have to rely on IP-number or something, good luck to all AOL'ers.

http://se.php.net/session

It seems pretty complicated.

Quote:

Original post by Dave It seems pretty complicated.

How so? The server handles everything, all you have to do is call a function now and then. Before the days of built in session handling you'd have to keep track of all that yourself, now you have pre-built functions doing it for you.

I.e. doesn't get much easier.

If you wanna do it by hand:

1) Generate unique session id (md5 username+login time+secret passphrase, or somesuch), save to relational database identifying a certain user with the session id - set a cookie or return a URI with the session id to the client browser (propagate the session id to all internal URI's on that page).
2) At every page load, check the cookie or the URI, extract the session id and check against database. Checking is done by doing the MD5 again (you have the username, login time and the secret passphrase in your database) and seeing if it matches what is given by the client.

Not overly complicated either, just more work.

[Edited by - Xipe on November 30, 2005 6:40:53 PM]

I suppose if cookies are disabled the password will md5 hashed so even if it does go in the url it's unreadable.

Quote:

Original post by Dave I suppose if cookies are disabled the password will md5 hashed so even if it does go in the url it's unreadable.

Yes, both the value in the stored cookie (or) the appended id to the URL will be gibberish, it's just a random (but unique) value for that session that is then identified with a certain client (i.e. user) that validated in the first place (you'd start the session at a correct login for instance).

Be sure that you don't think, "well, the password is md5ed before I send it, so no one can find out the password, so the login is secured." If all they need to send is the md5ed password, all an attacker would need would be the md5 hash of the password. That is, who cares what the password is when all you need is the hash of the password?

Eventually you are going to have to send a vital piece of information over http. Cookies don't prevent that fact and neither do sessions. If you are really worried about security, you will need to use a different protocol (e.g. https).

Quote:

Original post by rileyriley Be sure that you don't think, "well, the password is md5ed before I send it, so no one can find out the password, so the login is secured." If all they need to send is the md5ed password, all an attacker would need would be the md5 hash of the password. That is, who cares what the password is when all you need is the hash of the password? Eventually you are going to have to send a vital piece of information over http. Cookies don't prevent that fact and neither do sessions. If you are really worried about security, you will need to use a different protocol (e.g. https).

The MD5 you use is usually generated from several entities (at least one will be random), and using the password in that doesn't matter much since the whole string is then MD5'd or otherwise one-way encrypted. I don't think you understand the concept fully as the session id will be different for _every_ login the _same_ user makes and never leave any clue as to passwords.

HTTPS is only useful to protect against sniffers, and that's a legitimate concern in itself, but has _nothing_ to do with the safety of the session id generation. You can hi-jack HTTPS sessions too - what a session id generated like this does is making it near impossible to hi-jack a session by guessing.

HTTPS only prevents someone from snapping up your login and password (and later on your session id) by listening to network traffic and using it while you are online. That's why online stores and sites that store important personal or financial data use HTTPS starting at login, and general forums usually don't (not worth the hassle and extra bandwidth).

[Edited by - Xipe on November 30, 2005 8:54:33 PM]

I've pretty much decided to leave the sessions til last and get the rest of the project done. Although i will bookmark this, thanks for the help.

Dave

Quote:

Original post by Xipe Quote: Original post by rileyriley [...] Eventually you are going to have to send a vital piece of information over http. Cookies don't prevent that fact and neither do sessions. If you are really worried about security, you will need to use a different protocol (e.g. https). The MD5 you use is usually generated from several entities (at least one will be random), and using the password in that doesn't matter much since the whole string is then MD5'd or otherwise one-way encrypted. I don't think you understand the concept fully as the session id will be different for _every_ login the _same_ user makes and never leave any clue as to passwords. HTTPS is only useful to protect against sniffers, and that's a legitimate concern in itself, but has _nothing_ to do with the safety of the session id generation. You can hi-jack HTTPS sessions too - what a session id generated like this does is making it near impossible to hi-jack a session. HTTPS only prevents someone from snapping up your login and password by listening to network traffic and using it while you are online. That's why online stores and sites that store important personal or financial data use HTTPS at login and general forums usually don't.

I should have been more clear - I was responding to the following:

Quote:

I suppose if cookies are disabled the password will md5 hashed so even if it does go in the url it's unreadable.

I wanted to emphasize that, all other issues aside, md5ing a password on both sides does not create more security in the transmission. I wasn't meaning to refer to session IDs.

My understanding of sessions (and I just found this out recently) is that the session ID is stored either in a cookie, or in the URL for browers that don't have cookies enabled. The session ID allows you to have access to all session variables associated with that ID, but doesn't allow you to view what the values are (and someone correct me on this if I'm wrong). So... if I have the following:

SessionID = 2a3sdf41df34kljahsdf-9q80w75rln

The server would know to access the values of $MyVar['SessionID']['UserName'] as I progress from page to page (thus keeping track of who it thinks I am), but I'd have no way of extracting what the values of $MyVar['SessionID']['Variable'] is from the server. So, while I 'could' hijack a session ID, make it into a cookie, and gain a good bit of control over the users account so long as the session hasn't expired... it would all be of no real use to me if the website requires that I re-enter my password before doing anything critical (like, bring up credit card information for the account, etc.). Of course, you're not going to have a login screen right before links such as 'view my favorites', 'view my buddy list', etc. But, if you had a page setup that required data from post variables, and didn't look at session variables, you'd 'have' to know the username/password to get in.

Whew. At any rate, unless you're working with highly sensative information, I'd suggesting setting your pages up as I showed before. Use the $_Session naming convetion if you're more comfortable with it. And if you feel the need to save it for last (which is probably a good idea if you don't have much work done), then cool.