munsiem Posted May 24, 2008 Share Posted May 24, 2008 I am trying to get a good idea on what would be best for site security (such as login accounts holding personal user information), and I was wondering if using Session Variables is the way to go. Quote Link to comment Share on other sites More sharing options...
TheFilmGod Posted May 24, 2008 Share Posted May 24, 2008 Yes it is. The only alternative I can think of are cookies, but they store information on a user's computer - a great security risk. Overall, sessions are the best way to go. However, if you are transferring social security numbers or credit card digits - make sure you get a SSL (HTTPS) connection/certificate. Quote Link to comment Share on other sites More sharing options...
munsiem Posted May 24, 2008 Author Share Posted May 24, 2008 Thanks a lot - guess I will learn how to get that certificate going. Quote Link to comment Share on other sites More sharing options...
KevinM1 Posted May 24, 2008 Share Posted May 24, 2008 Yes it is. The only alternative I can think of are cookies, but they store information on a user's computer - a great security risk. Overall, sessions are the best way to go. However, if you are transferring social security numbers or credit card digits - make sure you get a SSL (HTTPS) connection/certificate. You do realize that sessions, by default, use cookies, right? Quote Link to comment Share on other sites More sharing options...
mithras Posted May 24, 2008 Share Posted May 24, 2008 It's true that sessions are with the default php session handler using cookies following the http protocol. But still sessions and cookies are a safe way for user logins. If you use a challenge/response system (with a non-javascript fallback system) you can safely (enough...) login. If you store the session id in a session and user specific information in a database session table (e.g. id, session, user id, last visit and ip) it's a really stable system. I you sent critical data (credit card numbers, username/password for critical systems) it's better to use https, but it cost more (development, certificates etc) to use it. Quote Link to comment Share on other sites More sharing options...
TheFilmGod Posted May 25, 2008 Share Posted May 25, 2008 Yes it is. The only alternative I can think of are cookies, but they store information on a user's computer - a great security risk. Overall, sessions are the best way to go. However, if you are transferring social security numbers or credit card digits - make sure you get a SSL (HTTPS) connection/certificate. You do realize that sessions, by default, use cookies, right? Sessions and Cookies are two separate measures of transferring user data from one page to another. It is true that the two have some overlap at some points, but when they do, they render the other as useless. When you start a session, the server temporarily saves a session log of your stay. This contains all session information, as well as the id of the user. The user on the other hand, is given a small piece of code, an id of his session. Sometimes this is incorrectly assumed as a cookie (as Nightslyr does), but in no way is an actual cookie. Its more of a placeholder that tracks the user's id of his session so the server <--> browser can communicate. Therefore, your statement is incorrect, because this "placeholder" is not a cookie, but an identification card. Quote Link to comment Share on other sites More sharing options...
GingerRobot Posted May 25, 2008 Share Posted May 25, 2008 In what way does a session not set a cookie? It doesn't really matter what it stores; it's still a cookie. http://uk2.php.net/manual/en/session.idpassing.php Quote Link to comment Share on other sites More sharing options...
munsiem Posted May 25, 2008 Author Share Posted May 25, 2008 Thanks for all the input. For what I am using right now is user logins and members only pages. The only thing I was worried about is storing personal information about the users. The HTTPS is a good suggestion when I upgrade to collecting data such as credit card numbers. This all helps a lot! Thanks Quote Link to comment Share on other sites More sharing options...
Daniel0 Posted May 25, 2008 Share Posted May 25, 2008 Therefore, your statement is incorrect, because this "placeholder" is not a cookie, but an identification card. That is essentially what a cookie is. Take a look at the HTTP protocol again and try to monitor the headers sent between your browser and the server. You'll notice that when initializing a session, the server will have a Set-Cookie header which sets a cookie called PHPSESSID. On the following requests your browser will send a header called Cookie containing that (and possibly other) cookies. If cookies are not available, then it will be passed in the URL. Quote Link to comment Share on other sites More sharing options...
448191 Posted May 25, 2008 Share Posted May 25, 2008 Sessions and Cookies are two separate measures of transferring user data from one page to another. It is true that the two have some overlap at some points, but when they do, they render the other as useless. When you start a session, the server temporarily saves a session log of your stay. This contains all session information, as well as the id of the user. The user on the other hand, is given a small piece of code, an id of his session. Sometimes this is incorrectly assumed as a cookie (as Nightslyr does), but in no way is an actual cookie. Its more of a placeholder that tracks the user's id of his session so the server <--> browser can communicate. Therefore, your statement is incorrect, because this "placeholder" is not a cookie, but an identification card. Please. 1) A has been noted (twice) PHP's session management system uses cookies by default. The cookie contains a session ID. 2) Sessions are not a measure "of transferring user data from one page to another". A "session" simply refers to period of time in which a state between parties is maintained. In web applications, these parties are a client and server. A 'session' even in the specific context of a PHP application, is not a method of transferring data. Hence the PHP session management extension has to rely on URI arguments or cookies to transfer the session ID. I cannot believe how many times I have had this discussion. Sessions in PHP are not magic. More specific to the OP, sessions in web applications are far from inherently secure. Sure, since the actual data never leaves the server, you can be certain that, in contrary to using cookies, what's in there was put there by the server. The Achilles heel of using a traditional session management system is the session ID. Risks can mostly be categorized in 'Session Hijacking' and 'Session Fixation'. Some quick advice that goes a long way towards making your session more secure: use session_regenerate_id() whenever the client is about to do something of interest. Pseudo-officially, the credo is to regenerate the ID whenever 'the users access level changes'. A login most certainly qualifies. Quote Link to comment Share on other sites More sharing options...
TheFilmGod Posted May 26, 2008 Share Posted May 26, 2008 2) Sessions are not a measure "of transferring user data from one page to another". Then what are they intended for? Keeping a magical state between the client and server? Quote Link to comment Share on other sites More sharing options...
448191 Posted May 27, 2008 Share Posted May 27, 2008 2) Sessions are not a measure "of transferring user data from one page to another". Then what are they intended for? Keeping a magical state between the client and server? Not magic, but yes. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.